Hi David,
Of course we would like to see the packages at jpackage.org, too, but I
understand that FC wants some added value. The problem is also that
jpackage.org has no strategy (and no strategy has been proposed) for
binary
packages. This means that while jpackage.org was once a nice place to
get Java
packages for any RPM distro, now the work needs to be duplicated---not
only
duplicated for every distro, but at jpackage.org as well.
I think JPackage guys can agree on a strategy for binary packages and
all distros can be compatible with jpp packages if they want to. As far
as I understand gcj on FC4 uses the gij interpreter to start Java
applications, and so using Kaffe, Sun Java or any other jvm should not
impact the Java app, and it used *.db files to replace the bytecodes by
native code at runtime. So the inly difference are the *.so files and
the corresponding *.db files.
I guess it was already sugested on the list putting the native files on
a separate package, and this package only is deppendent on libgcj and
gij. Someone expressed concerns about users installing a Java app (say
Tomcat) from it's rpm package but not the native rpm and so getting poor
performance, but I think that's something users can find out on the FAQ
or mailing list.
For big apps (and optmizations like the use of native Java libraries)
I'd like to have some kind of "meta-package" just like Familiar Linux
uses. They have, for example, a language-pt package that install the
keyboard layout, locale files and message files for all applications,
but just for installed ones. So it's easy to add support for some
language without bloating the limited flash space on a PDA with
thousands of language files like desktop distros do.
Instead of having to remember to install tomcat-webapps and the like, or
relying on yum and up2date to find dependencies (which are not allways
all I'd like to have on a default install) I'd use "rpm -i
tomcat-complete" and this packages directs to install everything it needs.
So FC could have meta-packages requiring both native and bytecode
packages, and the bytecode packages (and even the native ones) could be
jpp ones.
If you ever tried to install Gnome, OpenOffice or Apache with PHP and
lots of modules installed by hand, you'd love to have that meta-package
concept. That's something like that Anaconda does, presenting the user
categories of packages instead of individual rpm files, but more granular.
[]s, Fernando Lozano
