-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, 8 Jul 2001, Axalon wrote:
[Java]
>Precedence set by Kaffe pkg, which is atleast in theory compliant with the
>standard. /usr/java should be broke apart into /usr/lib, /usr/bin, and
>/usr/share/"name".
I agree, but try telling Sun that :-P.
I think that we should let Sun have their stupid broken /usr/java/ for
the official Sun JDK and related packages. But we shouldn't use that
directory for any new stuff.
>"Global libs" (for lack of knowledge?) would get installed into the
>generic CLASSPATH (/usr/share/"kaffe\jre\jdk\java"/lib),
Do you mean that Kaffe has its own directory for class files, like
/usr/share/kaffe/whatever/lib/. and that other Java environments would
have a different directory?
I think it would be much better to have a single directory for 'all
globally-installed Java libraries'. Of course the individual Java
implementations can have their own directories too, but there should be
one definite place where libraries can be installed.
Suppose I wanted to package the Java version of the Xerces XML parser.
What directory should the RPM install into? If it installs into
/usr/share/kaffe/... then the library wouldn't work with the Sun or IBM
JDKs. If it installs somewhere else, it wouldn't work with Kaffe, and
so on.
So while it is okay for Kaffe to have its own lib directory (perhaps
for 'system' packages which are specific to that JVM), there needs to be
a way to install a Java library and have it Just Work.
>where as application specific would create thier own dir under
/usr/share/"prog\pkg" and use a wrapper to alter the CLASSPATH.
Yes, that sounds sensible. Things like ant, the Java build tool, could
do that. Although you do want to avoid libraries being installed as
'application specific' when in fact they are just libraries which could
be used elsewhere.
>This doesn't mean a socalled global HAS tobe put into
>the global path, they could all be stuffed into /usr/share/"prog\pkg" to
>allow for version mixing..
I think that *if* an application needs a specific version of some
library, and this is some wacky version that isn't likely to be used
by anyone else, then it's okay for that application to have its own copy
of the class files.
However, if you get an app which just says 'this requires the
com.foo.bar packages', then that library should be installed as a
separate library package, if it is distributable.
With C programs, Linux distributions don't allow much messing around
with specific versions of libraries. We don't allow gif2png to use
version 1.2.3 of libpng while xemacs needs version 1.4.6. They should
both be compiled to use some common version, probably the latest stable
version, and if gif2png doesn't work with the latest libpng, then that
is a bug. In cases of incompatible new versions (normally a major
version number change, as in Qt 1.x vs 2.x), the two versions may both
be installed with a small name change to distinguish them, but even then
the older version disappears as soon as possible. Distros don't allow
prima donna applications that insist on having *that* exact version of a
particular library and carrying it around with them.
Java has not yet developed a good mechanism for making sure that a
standard set of libraries is installed, so often you find prepackaged
apps including their own copies of libraries because this is easier than
telling the user 'first go and install X, then Y and Z...'. But if you
can get the stuff properly packaged and the dependencies noted, there is
no need for all this.
We should try as hard as possible not to have application-specific bits
of library installed in random places. Especially not to have fifteen
slightly different implementations of org.w3c.xml.DOM or whatever. But
of course class files which are specific to one application are okay,
and should be installed in that application's own directory.
- --
Ed Avis <[EMAIL PROTECTED]>
Finger for PGP key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7SWkEIMp73jhGogoRAl+CAJ0dYN7V9flmBtAmkzF6cTfTICjhPACcCxT/
2OQDlkRyW+x3VrOHA8pipgU=
=SXKx
-----END PGP SIGNATURE-----
