FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development Java

 
 
LinkBack Thread Tools
 
Old 02-17-2012, 07:01 AM
Aleksandar Kurtakov
 
Default Fedora vs JPackage naming

Time to give my POV here .

----- Original Message -----
> From: "Andy Grimm" <agrimm@gmail.com>
> To: "java-devel" <java-devel@lists.fedoraproject.org>
> Sent: Thursday, February 16, 2012 9:21:02 PM
> Subject: [fedora-java] Fedora vs JPackage naming
>
> After running into a few complicated naming situations, I decided it
> would be worthwhile to pose this question to the list. For context,
> the current Fedora package naming guidelines say this:
>
> "When naming a package, the name should match the upstream tarball or
> project name from which this software came. In some cases, this
> naming
> choice may be more complicated. If this package has been packaged by
> other distributions/packagers in the past, then you should try to
> match their name for consistency. In any case, try to use your best
> judgement, and other developers will help in the final decision."
>
> In the java world, a few issues come into play.
>
> 1) the history of jpackage naming, where a packages are often named
> according to the section of the apache project from which they came.

I would say keeping jpackage compatibility but if upstreams have moved/changed, the jpackage name is ambiguous nowadays or even there is a name that matches other things in fedora better we can live without this compatibility.

>
> 2) the upstream tarball naming and jar file names, which typically
> lack the "ws-commons" prefix.

There are too many Java projects that have all 3 (project, tarball, jar) names differ or even worse jars from the same
tarball/projects use different name schemes. This is a case where I think we don't have better solution but to trust the
packager and the reviewer working on the package to come with the best package name. I doubt anyone can come up with a policy
that is less than stupid if the upstream project can not cope with that.

>
> 3) the existing Fedora packages, where we have apache-commons-* ,
> xml-commons-*, one ws-commons-* package, and one ws-* package.

I would say that these package names are because of legacy reasons.
WS/XML projects have sub-projects floating around in them and commons is just to common to mean something.
We can even use just codec/lang if we go on removing the unneeded parts. That's why we have always had them fully prefixed - jakarta-commons, apache-commons and etc. I don't see a good reason to change that.

>
> 4) apache's own naming in github is different from their svn naming
> (partly due to a lack of hierarchy):
>
> https://github.com/apache/webservices-axiom
>
> versus
>
> http://svn.apache.org/viewvc/webservices/commons/tags/axiom/

As apache doesn't have official git repo probably we should not care about that until they come up with one.

>
> 5) If we go with short names (to match the jar files), we have a
> greater risk of collision with other project names, e.g.,
> http://savannah.nongnu.org/projects/axiom
>
> So I look at all of these conflicting possibilities, and I think we
> need to come to some consensus about what to do here. I considered
> posting this to the packaging list, but I think it's a fairly
> java-centric problem at this point. Feel free to report on that list
> if you believe it's appropriate, though.

My opinion is that we should try to match the artifactId in the maven case and if it looks ambiguous add the project name as we currently do.
I really trust packagers to make the right choice. Once there is an all Java land module system this things will settle down. I really encourage people
interested in this area to join the Jigsaw/Penrose projects and help people there to come up with a module system that will work for us. We don't have to think of package names and etc. because until there is a heavily used module system in the JVM we would never manage to have proper and sensible naming. Until then I don't see better choice than going on case by case.

P.S. Every mass package rename with Jigsaw scheduled for Java 8 would do nothing more but enhance the mess.

Alex

>
> (And if this topic has already been beaten to death, I apologize. I
> couldn't find a documented resolution, though.)
>
> Thanks.
>
> --Andy
> --
> java-devel mailing list
> java-devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/java-devel
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel
 
Old 02-17-2012, 07:05 AM
David Walluck
 
Default Fedora vs JPackage naming

On 02/17/2012 02:41 AM, Aleksandar Kurtakov wrote:
> of jars manually) I can understand the reasoning. Plus in the
> guidelines there is a statement that if package installs more than 2
> jars they should go into _javadir/name/ which at least for me makes
> it perfectly viable place for installation if your package is coming
> from the same source and you depend on that previous package. I'm

As to the non-flat dir structure and renaming of jars:

Does it work with ant out of the box? No.
Does it work with ivy out of the box? No.
Does it work with gradle out of the box? No.
Does it work with maven out of the box (without the depmap hack)? No.

So, my preference stems from these requirements and not what the
guidelines currently say or what the packager prefers. I'd prefer a new
guideline that meets all four requirements above.
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel
 
Old 02-17-2012, 07:35 AM
Aleksandar Kurtakov
 
Default Fedora vs JPackage naming

----- Original Message -----
> From: "David Walluck" <david@zarb.org>
> To: java-devel@lists.fedoraproject.org
> Sent: Friday, February 17, 2012 9:59:18 AM
> Subject: Re: [fedora-java] Fedora vs JPackage naming
>
> On 02/17/2012 02:29 AM, Aleksandar Kurtakov wrote:
> > I've spend enough time on getting this working and it really is
> > now.
> > If your package installs pom.xml file it will have Provide:
> > mvn(gid:aid) If your package is an osgi bundle it will have
> > Provide:
> > osgi(bundle-symbolic-name) If it installs pom.xml and is osgi
> > bundle
> > it will have both Provides. When in doubt just use that or use yum
> > to
> > tell you the package name.
>
> Does it set the version properly too? I know that certain characters
> are
> not allowed in the RPM version string so it would have to normalize
> it
> somehow. Currently, we don't have this on RHEL 6, so I haven't
> actually
> seen it in action.

Yes, there is Provides: osgi(org.apache.commons.codec) = 1.6.0 for apache-commons-codec. I'm not aware of the characters problem for the osgi case and versions in the maven case doesn't make sense as we ignore them. Though having the version in the provides wouldn't hurt - if someone wants to enhance the maven provides generator - the code is at http://git.fedorahosted.org/git/?p=javapackages.git . Assuming that others are more interested in the maven case I'll be happy to guide them in achieving this. I get it to the point where it serves the generic Fedora case well and let the community enhance it if someone needs the version.
RHEL is out of question in this thread and I would not comment it at all here.
>
> The Fedora Release tag policy prevents proper versioning of
> BuildRequires since important parts of the version string end up in
> the
> Release tag for no good reason. Since RPM compares both the V and the
> R,
> moving things from V to R doesn't really make sense. RPM also
> compares
> text strings in both, and while it may not exactly match how maven or
> osgi compares, I think it's better than nothing and at least
> internally
> consistent.

Well, I'm not sure how the release tag will be a problem if e.g. using Requires: osgi(org.apache.commons.codec) >= 1.6.0 . Note that the bundle version is used not the package version so the release is irrelevant unless we try to fight other issues with this like class versions, apiincompatibilities and etc. which are different problems in my eyes.

>
> > I don't understand this point. We can not use maven gid:aid or osgi
> > symbolic-name as package names. The mess will become way bigger in
> > this case - it will be: * for maven packages use gid-aid as package
> > names * for osgi packages use symbolic names * for jars that are
> > neither - stick to the project names * for packages that are both
> > maven and osgi ? - should we give the packager a choice? I don't
> > feel
> > it's right to ask osgi developers to care about maven and
> > vise-versa
> > so letting the packager makes a choice seems like the right choice.
>
> I guess I would say to just pick one. If we have a policy that each
> package must have a POM (or OSGI support---your choice), then each
> package is also guarnateed to have a unique name in those systems.

Yes, but we already have too few contributors and trying to force them either the osgi or maven route will probably make them stop contributing.
That's why I think we can not make this choice until there is a defacto module system.


>
> > But just imagine the mess this will be !!! I'm definetely not
> > looking
> > for this. People should learn to use the virtual provides for the
> > time being (until there is suitable! module system in java world).
>
> OK, you have some point to this in that we can start using these
> names
> and pretend that the package name doesn't exist. But this only works
> if
> the artifact names and locations are fixed too, right?

Well, we are working hard on this too and such cases are very rare nowadays but if there is something this is a bug and deserves a bug report.

>
> > I'm really tired of seeing this remarks. It is my choice to make
> > this
> > tool this way and people should respect that. Everyone is free to
> > come with better(where better means more suitable for him) ones
>
> I never said anything bad about your tool. If you look at what I
> said,
> my choice was 100% driven by bandwidth concerns and my crappy
> internet
> speed. It had nothing to do with software even. As I think you know,
> I
> used to use Eclipse a lot in the past (especially when I was doing
> Java
> development), and if I was able to do development on my local machine
> I'd probably be using it now.
>
> So again, I have nothing bad to say about your tool. But, I wonder if
> parts of it are not tied to the GUI, then we could prehaps reuse a
> lot
> of code to provide a headless solution? I am not saying that you (or
> I)
> would be willing to code such a thing, but I am wondering if it makes
> sense.

Sorry David, I'm bit touchy on the subject because I see these remarks too often and most of the time from people that haven't even tried something. My reply is because of my personal feelings about the topic and how will a number of people read it (though I know exactly what you ment) that's why I commented it.
There are still options to use eclipse locally with projects on remote filesystem but this thread is not the right place.
Technically it is adding one class implementing IApplication that will call the command with the correct parameters that will allow people to run it headless(without gui) aka eclipse -application myapp . If there is anything else needed in the code I'll be happy to do it but I would not drive such an effort myself. I care for people being able to use my work but people should be ready to step in .

>
> > There is one huge difference here - perl and python are modulized
> > upstream, with every module having it's own tarball an release
> > (most
> > of the times). Thus this comparison is irrelevant here until this
> > happens upstream in java land.
>
> So, should we wait for Jigsaw? Will Jigsaw actually solve anything?
> If
> yes, then we could at least start to plan for it.

Wait - no . Jigsaw is work in progress AFAIK so people should join there and help drive it for our needs.

>
> > If we want to be more of a product than a bunch of random packages
> > I
> > think that this things should be set distro wide so there are no
> > distro wide and enforced in a way that we don't see the current
> > mess.
>
> Good point. But if there were such specific standards, a tool can
> generate to such standards, and rpmlint already exists to complain
> about
> such things, although I don't know that it's actually deployed for
> Fedora.

Rpmlint is supposed to be used during review but I would not say it's deployed distro wide. At least not in the way it was at Mandriva - with build system rejecting builds on certain rpmlint errors. But this is fight I'm not ready to step in.

Alex

> --
> java-devel mailing list
> java-devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/java-devel
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel
 
Old 02-17-2012, 07:43 AM
Aleksandar Kurtakov
 
Default Fedora vs JPackage naming

----- Original Message -----
> From: "David Walluck" <david@zarb.org>
> To: java-devel@lists.fedoraproject.org
> Sent: Friday, February 17, 2012 10:05:01 AM
> Subject: Re: [fedora-java] Fedora vs JPackage naming
>
> On 02/17/2012 02:41 AM, Aleksandar Kurtakov wrote:
> > of jars manually) I can understand the reasoning. Plus in the
> > guidelines there is a statement that if package installs more than
> > 2
> > jars they should go into _javadir/name/ which at least for me makes
> > it perfectly viable place for installation if your package is
> > coming
> > from the same source and you depend on that previous package. I'm
>
> As to the non-flat dir structure and renaming of jars:
>
> Does it work with ant out of the box? No.
-1 Nothing works with ant out of the box.

> Does it work with ivy out of the box? No.
+1 but there are only a few packages in Fedora that use ivy.

> Does it work with gradle out of the box? No.
-1 Well, gradle is not in Fedora and there is no one working on it. It's design is so badly broken that it will not work for pure source builds without network access without a major rewrite so I don't care about it until this happens.

> Does it work with maven out of the box (without the depmap hack)? No.
-1 For something to work with maven out of the box there has to be a maven repo. But files installed only in maven repo will fail usage from all other build systems. This can be achieved but it's maven specific development thus irrelevant to the general considerations.

Does it work with pde.build out of the box? No.
-1 Nothing works with pde.build out of the box.

Does it work with tycho out of the box? No.
-1 This is actually in the same both as maven - it needs it's p2 repo but this is smth the people that care for maven should do - fix/extend their own stuff.

So the only solution that at least have chances to satisfy our needs is Ivy .

Alex


>
> So, my preference stems from these requirements and not what the
> guidelines currently say or what the packager prefers. I'd prefer a
> new
> guideline that meets all four requirements above.
> --
> java-devel mailing list
> java-devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/java-devel
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel
 
Old 02-17-2012, 08:06 AM
David Walluck
 
Default Fedora vs JPackage naming

On 02/17/2012 03:35 AM, Aleksandar Kurtakov wrote:
> Yes, there is Provides: osgi(org.apache.commons.codec) = 1.6.0 for
> apache-commons-codec. I'm not aware of the characters problem for the
> osgi case and versions in the maven case doesn't make sense as we
> ignore them. Though having the version in the provides wouldn't hurt

I would like to, for example, BuildRequires >= <version in pom>. I give
a specific example later on.

> someone needs the version. RHEL is out of question in this thread and
> I would not comment it at all here.

All I mean is that the changes apparently require changes to RPM itself
so that unlike jpackage-utils macros, the changes are not portable.
Unless I am mistaken. For example, we can install jpackage-utils on RHEL
(or anywhere else) and immediately get the support for various macros, etc.

> Well, I'm not sure how the release tag will be a problem if e.g.
> using Requires: osgi(org.apache.commons.codec) >= 1.6.0 . Note that
> the bundle version is used not the package version so the release is
> irrelevant unless we try to fight other issues with this like class
> versions, apiincompatibilities and etc. which are different problems
> in my eyes.

A typical jboss version 1.0.0.CR2. I would like to say >= 1.0.0.CR2.
But, I can't, because it's 1.0.0-99.CR2 or something instead. Even
though putting the CR2 in the version string would be absolutely fine
except that it violates some stupid policy that is apparently not based
on actual RPM versioning semantics and again some abitrary prefs of some
people.

> Yes, but we already have too few contributors and trying to force
> them either the osgi or maven route will probably make them stop
> contributing. That's why I think we can not make this choice until
> there is a defacto module system.

There is no policy that already dictates, e.g., support for maven?

> Well, we are working hard on this too and such cases are very rare
> nowadays but if there is something this is a bug and deserves a bug
> report.

Well, package xerces-j2 historically installed xerces-j2.jar, but it
should have been xercesImpl.jar all along because this is what
everything and everybody expects.

> exactly what you ment) that's why I commented it. There are still
> options to use eclipse locally with projects on remote filesystem but
> this thread is not the right place. Technically it is adding one

Yes, I know some things such as sshfs, but anyway.
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel
 
Old 02-17-2012, 08:10 AM
David Walluck
 
Default Fedora vs JPackage naming

On 02/17/2012 03:43 AM, Aleksandar Kurtakov wrote:
> So the only solution that at least have chances to satisfy our needs is Ivy .

The point is that something as simple as
%_javadir/<artifactId>-<version>.<extension> probably satisfies 3 out of
4 requirements, and ivy also supports maven artifact patterns (really,
it is just another location, which could be a simple symlink).

So I would agree with you if supporting these crazy builds systems
requires a lot (or even a little) extra work.

But it seems to me that we get support for free (or at least as best we
can, by sticking to the simple flat dir and naming structure above).
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel
 
Old 02-17-2012, 08:42 AM
Aleksandar Kurtakov
 
Default Fedora vs JPackage naming

----- Original Message -----
> From: "David Walluck" <david@zarb.org>
> To: java-devel@lists.fedoraproject.org
> Sent: Friday, February 17, 2012 11:06:21 AM
> Subject: Re: [fedora-java] Fedora vs JPackage naming
>
> On 02/17/2012 03:35 AM, Aleksandar Kurtakov wrote:
> > Yes, there is Provides: osgi(org.apache.commons.codec) = 1.6.0 for
> > apache-commons-codec. I'm not aware of the characters problem for
> > the
> > osgi case and versions in the maven case doesn't make sense as we
> > ignore them. Though having the version in the provides wouldn't
> > hurt
>
> I would like to, for example, BuildRequires >= <version in pom>. I
> give
> a specific example later on.

This should work just fine once someone implements adding version information to the maven provides generator assuming you stick to using the mvn(gid:aid) format.
>
> > someone needs the version. RHEL is out of question in this thread
> > and
> > I would not comment it at all here.
>
> All I mean is that the changes apparently require changes to RPM
> itself
> so that unlike jpackage-utils macros, the changes are not portable.
> Unless I am mistaken. For example, we can install jpackage-utils on
> RHEL
> (or anywhere else) and immediately get the support for various
> macros, etc.

Nope, no changes to RPM itself are required. RPM provides an extension point for dependency generators which we have implemented in entirely separate project and shipped with jpackage-utils in Fedora for quite some time. See http://www.rpm.org/wiki/PackagerDocs/DependencyGenerator for details.

>
> > Well, I'm not sure how the release tag will be a problem if e.g.
> > using Requires: osgi(org.apache.commons.codec) >= 1.6.0 . Note that
> > the bundle version is used not the package version so the release
> > is
> > irrelevant unless we try to fight other issues with this like class
> > versions, apiincompatibilities and etc. which are different
> > problems
> > in my eyes.
>
> A typical jboss version 1.0.0.CR2. I would like to say >= 1.0.0.CR2.
> But, I can't, because it's 1.0.0-99.CR2 or something instead. Even
> though putting the CR2 in the version string would be absolutely fine
> except that it violates some stupid policy that is apparently not
> based
> on actual RPM versioning semantics and again some abitrary prefs of
> some
> people.

Again, having proper mvn(gid:aid) = pom_version provides should serve this purpose. There should be just someone motivated to enhance the current generator.

>
> > Yes, but we already have too few contributors and trying to force
> > them either the osgi or maven route will probably make them stop
> > contributing. That's why I think we can not make this choice until
> > there is a defacto module system.
>
> There is no policy that already dictates, e.g., support for maven?

If it's build with maven, maven integration is a MUST.
Otherwise maven integration is a SHOULD which I read as non-mandatory (aka you can choose to not deal with it) but nice-to-have (aka you can't object if someone else does it).

>
> > Well, we are working hard on this too and such cases are very rare
> > nowadays but if there is something this is a bug and deserves a bug
> > report.
>
> Well, package xerces-j2 historically installed xerces-j2.jar, but it
> should have been xercesImpl.jar all along because this is what
> everything and everybody expects.

Well, xml libs are so many and so different that we all would live in a better world once projects learn to use the xml apis in the JDK. So the right fix for this one in my eyes is fix your project to not depend on xerces instead of care how is it packaged.

Alex

>
> > exactly what you ment) that's why I commented it. There are still
> > options to use eclipse locally with projects on remote filesystem
> > but
> > this thread is not the right place. Technically it is adding one
>
> Yes, I know some things such as sshfs, but anyway.
> --
> java-devel mailing list
> java-devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/java-devel
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel
 
Old 02-17-2012, 08:49 AM
Carlo de Wolf
 
Default Fedora vs JPackage naming

On 02/17/2012 10:10 AM, David Walluck wrote:

On 02/17/2012 03:43 AM, Aleksandar Kurtakov wrote:

So the only solution that at least have chances to satisfy our needs is Ivy .

The point is that something as simple as
%_javadir/<artifactId>-<version>.<extension> probably satisfies 3 out of
4 requirements, and ivy also supports maven artifact patterns (really,
it is just another location, which could be a simple symlink).

So I would agree with you if supporting these crazy builds systems
requires a lot (or even a little) extra work.

But it seems to me that we get support for free (or at least as best we
can, by sticking to the simple flat dir and naming structure above).
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel


I just would like to see maven artifacts 'properly' installed in
/usr/share/maven/repository.

Then we can let upstream maven (and other tools) use that.

Carlo
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel
 
Old 02-17-2012, 08:53 AM
Aleksandar Kurtakov
 
Default Fedora vs JPackage naming

----- Original Message -----
> From: "Carlo de Wolf" <cdewolf@redhat.com>
> To: java-devel@lists.fedoraproject.org
> Sent: Friday, February 17, 2012 11:49:09 AM
> Subject: Re: [fedora-java] Fedora vs JPackage naming
>
> On 02/17/2012 10:10 AM, David Walluck wrote:
> > On 02/17/2012 03:43 AM, Aleksandar Kurtakov wrote:
> >> So the only solution that at least have chances to satisfy our
> >> needs is Ivy .
> > The point is that something as simple as
> > %_javadir/<artifactId>-<version>.<extension> probably satisfies 3
> > out of
> > 4 requirements, and ivy also supports maven artifact patterns
> > (really,
> > it is just another location, which could be a simple symlink).
> >
> > So I would agree with you if supporting these crazy builds systems
> > requires a lot (or even a little) extra work.
> >
> > But it seems to me that we get support for free (or at least as
> > best we
> > can, by sticking to the simple flat dir and naming structure
> > above).
> > --
> > java-devel mailing list
> > java-devel@lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/java-devel
>
> I just would like to see maven artifacts 'properly' installed in
> /usr/share/maven/repository.
> Then we can let upstream maven (and other tools) use that.

I would even say that this is the only viable solution for the maven and friends and this doesn't interfere with the other buildsystems so everyone that cares about Maven - Join Carlo and help him achieve that

Alex

>
> Carlo
> --
> java-devel mailing list
> java-devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/java-devel
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel��y�{���^���aj�!�� [��ƫrb��'������{�j�!� ޖ+ޯ'Z��^����u���z+���W ^j�!�)����x���o+6��ڶ*l� 0���ki���&#x1E5897;����� zw�jV���܆X��+�'uG"��4�Q �{�j�!��k�^����u���z+ �����{��� ����܆X��+������o(��]y�܆X��+���a#>'z�Z�^om5�9 MI4^q���h��]y�܆X��+���W^j�!�)����x �������{������"� 13�4�v����r���܆X��+�Z �^om5�9�MI4^q�ԏ��� ��W(���� ��m=��"������m���+� � ��W(�)�&�ק�+r��x��*x�|� {����Ǣ��
 
Old 02-17-2012, 08:55 AM
Carlo de Wolf
 
Default Fedora vs JPackage naming

On 02/17/2012 10:42 AM, Aleksandar Kurtakov wrote:

Well, package xerces-j2 historically installed xerces-j2.jar, but it
should have been xercesImpl.jar all along because this is what
everything and everybody expects.

Well, xml libs are so many and so different that we all would live in a better world once projects learn to use the xml apis in the JDK. So the right fix for this one in my eyes is fix your project to not depend on xerces instead of care how is it packaged.

Alex

What "everybody expects" is a very large quantifier. I can just be a
prick and say: hey, I did not expect that. ;-)


Depending on xerces might be a valid choice. I don't want to know the
actual requirements or arguments. But we should just be providing choice.


In this case: use the existing xerces rpm or do it yourself in the way
you like. :-)


Carlo
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel
 

Thread Tools




All times are GMT. The time now is 12:55 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org