Adam Heath <doogie@debian.org> writes: > Drop the '-' on the link target. Standard libraries do not have anything like > that. Don't drop the dash, think about: libmp311.jar That's confusing to users and programs. Shared libraries do have .so., but anyway there's no need to copy shlibs religously. > If an application wants to hide its internals, then it should not place the > jars into /usr/share/java. This would mirror the case of static .a files(see > -devel, the SDL/X thread), where the API is in flux, or not something upstream > wants to support. Seperating libraries from programs is a good thing, yes. > Also, it may be beneficial for java-common to register .jar/.war/.ear files > with /proc/sys/fs/binfmt_misc, and provide a wrapper script for running these. > This could keep each binary package from having to have its own wrapper > script, in addition to improving the usability of java in debian. Hmm, would the jars end up in /usr/bin, then? Or have symlinks? These would be better since you can have multiples point at the same jar. Should these "executables" be named foo or foo.jar? Another possibility is to just point the symlinks at the standard wrapper from java-common. In both cases it's unclear to me how the generic wrapper (invoked via symlink or binfmt_misc) would know which class to invoke. YACF? > The wrapper should ALWAYS append the default system classpath to the provided > classpath(either thru $CLASSPATH or -classpath). However, specifing > -jdk-target <jdkname> would change the notion of the default system classpath. >From a user's or admin's perspective it is easier to just set CLASSPATH (or another envvar) to the other JRE's classes than to tack an option to every java call. > When a java binary(or library for that matter) is compiled in debian, the > debian/rules file should use the short name for the jar(see scriptage above). > Then, when producing dependencies, it calls a short wrapper around > update-alternatives --display(or --config) The point of update-alternatives is to make overriding by the admin persistent. Do we really want to make this kind of screwing with library versions easy? > Additionally, all jvm providers, when updating alternatives for /usr/bin/java, > need to provide additional --slave links, in addition to the manpage slaves. I was under the impression that we wanted to keep VMs orthogonal to the standard library classes. -- Robbe
Attachment:
signature.ng
Description: PGP signature