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 [EMAIL PROTECTED] ~ $ 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). [EMAIL PROTECTED] ~ $ 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: [EMAIL PROTECTED] ~ $ 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. [EMAIL PROTECTED] ~ $ 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
