All:
I'm very much looking forward to working Java Policy and
Packaging issues at Debconf7.
There has been some great discussion about this recently
from Paul, Manfred, Matthew and others. And, of course,
there is a lot of documentation out there [1].
My proposal is that, if folks agree, that we now actively
list the issues that need to be addressed and work
towards revised (or at least new documentation for) Java Policy.
These start at the very practical level and move to more
generic -- pan-Linux Java Policy. We had some great
discussions along these lines at the most recent
DevJam at FOSDEM 2007 [2]. The overriding goal here is
that the experience for Java developers, packagers and
users on GNU/Linux is as comfortable as possible
("It Just Works!").
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:
Execution
---------
1. Handling alternative runtimes
Gracefully handle the co-existence of many different
runtimes (even multiple versions of one runtime).
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).
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.
4. Support for binfmt_misc?
Administration
--------------
5. Use the priority system for safe "default" behavior.
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).
7. GUI tools for making choices
(e.g. a GUI front end for update-java-alternatives).
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)
Packaging
---------
9. Debhelper tools to help packaging Java libraries and
applications easier and less error prone (e.g. dh_installjars,
cdbs extensions).
10. Filesystem conventions (FHS) for runtimes (e.g. /usr/lib/jvm)
and libraries (e.g. /usr/share/java).
11. Define virtual provides (free/non-free, which version
of the Java SE platform: 4, 5, 6, 7).
12. Future integration of the the packaging with
the Java Module System (JSR 277).
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)
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.
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?
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.
Regards,
--Tom
[1] some Debian Java documentation
avdyk in 2005
http://wiki.debian.org/CommonJavaPackaging
AldousPenaranda in 2005
http://wiki.debian.org/DebianJavaPackaging
Barry Hawkins in 2006
http://wiki.debian.org/Java/RoadMap
Ola Lundqvist
Stephane Bortzmeyer
http://www.debian.org/doc/packaging-manuals/java-policy/
Debian Java Packaging Project 2006
http://pkg-java.alioth.debian.org/
Debian GNU/Linux Java FAQ. 2006
http://www.debian.org/doc/manuals/debian-java-faq/
[2] http://blogs.sun.com/tmarble/entry/devjam_fosdem_slides
[3] Part of the Gentoo java-config-2 approach
http://rafb.net/p/QxST1h34.html
http://overlays.gentoo.org/proj/java/browser/projects/java-config-2/trunk/src/launcher.bash
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
