Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
> javac can also be called during package building.
FWIW, I think having a package build relying on /usr/bin/javac is a very
bad idea. You want to be absolutely sure that a package builds out of
the box, and IMHO this means you should explicitly build-depend upon
*and* call a complier that you know will work. Note that just the
build-depends is not enough, since /usr/bin/javac is currently under the
management of alternatives, and so there's no guarantee that javac
actually calls the compiler that you build-depended on.
> >/var/lib/java/ and place this jars in /usr/share/java. The JarDF must be
...
> What about /usr/share/java/<package name>.classpath ?
I agree that it belongs beneath /usr/share, not /var/lib. Note that the
FHS includes an explicit exception for distribution packaging support,
which is presumably why we have /var/lib/dpkg.
Having said this, I agree with Jan that it should not be in
/usr/share/java since this is already used to store JAR files. I'm not
fussy about where it is as long as it's beneath /usr/share.
b.
Reply to: