Re: GNU/Linux Java Policy and Packaging
Tom Marble kirjoitti:
>
> I think the right way to flesh out these ideas is to
> work them up on the Wiki, but to get started let
> me write some here. I realize most of this is already
> decided and works just fine... Again the purpose
> is discussion:
I can explain in more detail our system if you want to take the best bits.
>
> Execution
> ---------
> 1. Handling alternative runtimes
> Gracefully handle the co-existence of many different
> runtimes (even multiple versions of one runtime).
checked
betelgeuse@pena ~ $ eselect java-vm list
Available Java Virtual Machines:
[1] blackdown-jdk-1.4.2
[2] ibm-jdk-bin-1.4
[3] ibm-jdk-bin-1.5
[4] kaffe
[5] openjdk-1.7 user-vm
[6] sun-jdk-1.4 system-vm
[7] sun-jdk-1.5
[8] sun-jdk-1.6
[9] sun-jdk-1.6.0.02
[10] sun-jdk-1.7
[11] sun-jre-bin-1.5
[12] sun-jre-bin-1.6
>
> 2. Insure that the man pages correspond to the
> executables (e.g. 'man java' does the right thing
> for the current /usr/bin/java alternative).
betelgeuse@pena ~ $ env | grep MANPATH
MANPATH=/home/betelgeuse/.gentoo/java-config-2/current-user-vm/man:<snip
rest>
>
> 3. Gracefully handle all the features of a runtime
> (e.g. the union of all possible programs in
> a runtime, SDK, and also Java Plug-In).
> Certain implementations may not have all the
> executables (or plugin) and may need to rely
> on some default (or error handling) behavior.
checked:
betelgeuse@pena ~ $ GENTOO_VM="sun-jre-bin-1.6" javac -version
* javac is not available for sun-jre-bin-1.6 on i686
* IMPORTANT: some Java tools are not available on some VMs on some
architectures
>
> 4. Support for binfmt_misc?
>
Was toying with this at some point but should be quite easy to implement
using an init script and some helpers.
>
> Administration
> --------------
> 5. Use the priority system for safe "default" behavior.
>
Seems Debian specific.
>
> 6. Command line tools for making choices
> (e.g. update-java-alternatives).
> It would be really nice for there to be global
> defaults (priorities), system defaults, and then
> user settings (where feasible).
>
checked
>
> 7. GUI tools for making choices
> (e.g. a GUI front end for update-java-alternatives).
>
Would be nice yes.
>
> 8. It will be important to have some interface
> for runtime argument setting -- esp. for performance.
> The challenge here is that tunings (e.g. heap, collector,
> compiler, etc) are VM dependent. And the packager's
> default may not be a good system wide default.
> And users should be able to override these settings
> conveniently as well (e.g. for profiling/analysis,
> for production environments)
>
checked but could be documented better
>
> 10. Filesystem conventions (FHS) for runtimes (e.g. /usr/lib/jvm)
> and libraries (e.g. /usr/share/java).
Shouldn't really matter if you you can use something like java-config to
query the locations but of course Debian needs to have their own
internal policy.
betelgeuse@pena ~ $ java-config -p xalan
/usr/share/xalan/lib/xalan.jar:/usr/share/xalan/lib/serializer.jar
>
> Upstream and distro Integration
> -------------------------------
> 13. Common upstream watcher. As many distros are interested
> in new versions from the same upstream runtimes (and
> libraries and apps) it seems that there is an opportunity
> for us to collaborate at a community level on
> some sort of notification of upstream publication
> (i.e. something as simple as Atom/RSS for new versions)
freshmeat somewhat provides for this
http://meatoo.gentooexperimental.org/
>
> 14. Common package decomposition and interdependencies.
> Again as many of these applications are identical across
> distros (as are the libraries) we may be able to
> reduce our community "energy budget" on packaging if
> we can share the dependency graph despite packaging
> format differences.
>
Well sure dep graph are easy to share but that's not where most of the
time packaging things is spent.
>
> 15. Common upstream/downstream bug integration.
> Ideally if a bug is found in one distro it gets a
> tracking bug upstream... and then the upstream bug
> can point to all the distro specific bugs.
> Perhaps stated more generally -- wouldn't it be
> great if searching on "xcb protocol" would
> list Java issues on *all* distros?
>
I haven't tried it but bugzilla 3.0 should have some features towards
this. But this is not Java specific and KDE/GNOME etc would benefit if
one day something like this is working.
>
> Petteri Räty has pointed out some of the very interesting
> approaches that Gentoo uses in it's java-config-2
> structure [2] (I have more documentation that can go on the Wiki).
> I'm not proposing that Debian adopt java-config-2 wholesale, but
> I think the Gentoo is an excellent example for discussing
> different approaches to addressing these challenges.
>
There is lot's more to our stuff that we didn't cover so feel free to
ask me if you need more info.
Regards,
Petteri
--
Gentoo/Java project lead
Reply to: