On Mon, Sep 17, 2001 at 11:51:10PM +0200, Stefan Gybas wrote: > Ola Lundqvist wrote: > > > Yes it bothers me too. What bothers me more is that someone (I > > do not remember who) told me that I should name my package > > libxalan2-java instead of lib-xalan2-java. > > > This was probably me. I had a long discussion with Stephane Bortzmeyer > (original author of the Java policy) about this, but I don't remember if > it was on this list or in private mails. > > Anyway, the initial idea behind lib-XXX-java was to use the Java package > name, e.g. org.w3c.dom would be in a Debian package called > lib-org.w3c.dom-java. However, more and more Java software with classes > in different Java packages was released, so this was not suitable any > longer.
Ahh. I see. Now I understand the old lib-foo-java naming, thanks. > I then decided for my packages to use libXXX-java for libraries where > XXX is the name of the product/project, e.g. libxerces-java. Real > applications, i.e. not just JARs, like Tomcat were just named after > the project. These also depended on java-virtual-machine instead of just > java-common in the case of Java libraries. > > About the version: I'm not sure if it makes sense to include the version > in the package name. It might be appropriate in some cases, e.g. I'm > thinking about packaging Xerces 2.0 as libxerces2-java so Xerces 1.x and > 2.x can both be installed at the same time, but I don't see what we could > gain from libxerces1.3.1-java, libxerces1.4.1-java, ... Well that was my thought too. With vervion I ment part of the version that are interesting. Like libxalan2 or libxerces2. Not libxalan2.0.x, just as you said. But this should be more clear when I update the policy. > A different story is the naming of JARs inside the package. It might make > sense to include the version there, so instead of > /usr/share/java/xerces.jar I could use /usr/share/java/xerces-1.4.1.jar > and create a symlink or using alternatives. But then some suggestions > like automatically including all jars in /usr/share/java to the default > classpath cause duplicate and conflicting classes. > > Summary: I'm for using libXXX-java instead of lib-XXX-java (and with the > exception ofg libpgjava I'm already doing this) and I thing the version > number should be allowed in the package but not enforced. So we end up > with library packages named lib<projectname>[<version>]-java. Packages > containing applications (i.e. shell startup scripts in /usr/bin) should > just be named after the application without -java appended. Exactly what I have in mind, only with a better specification. :) > If everybody agrees to this scheme, I'll rename libpgjava (which was > created before there has even been a discussion about a Java policy) to > libpostgresql-java. I agree with this. Regards, // Ola > -- > Stefan Gybas > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- --------------------- Ola Lundqvist --------------------------- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---------------------------------------------------------------
