[fedora-java] Re: Fedora Core 5 Wishlist

[Gary Benson]

Gary Benson wrote:
> David Walluck wrote:
> > On the other hand, people want more compatibility. And I want less
> > (ideally no) duplication. So I would again ask for some policy that
> > separates native libs from the jars. Or at least maybe someone is
> > willing to put some real thought into it rather than dismissing it
> > outright.
> 
> Before fedora-devel-java-list was set up we had precisely this
> discussion internally, several times as it happens ;)  If I answer
> you quickly it's not because I'm dismissing it but rather that I've
> already thought long and hard about it beforehand.
> 
> I've been trying to dig out the discussion all morning, but I keep
> getting sidetracked with email.  So, if you'll bear with me a few
> moments longer...

Well, I'd forgotton just how much was said about it, but a brief
summary is that there were three methods proposed:

 1. Native code in the same rpms as the bytecode.
 2. Native code in separate rpms to the bytecode.
 3. Native code generated on user's machine.

Method 3, which hasn't been mentioned on this list, involved either
%post scriptlets or some kind of background job like slocate has.
It's main drawbacks were that native compilation is a hugely
computationally intensive process, particularly with aggressive
inter-class optimizations.  Many target machines simply wouldn't have
the RAM to do the job.  Even were this not the case, it can frequently
take hours, too long for a %post scriptlet, and using a background job
would mean that there'd be periods when your native code was not in
sync and your Java apps would run slowly.
 
Method 2, which is what you're proposing, has the following drawbacks
over Method 1:

 - There is no way at present to make rpm (yum, up2date, anaconda...)
   associate the native packages with the bytecode ones.  Users would
   have to manually install them in the first instance.

 - Installed native packages must Require their bytecode equivalents.
   Users could not upgrade a Fedora package with a JPackage one
   without manually uninstalling the native package first.

 - The native package would not have access to the sources, and would
   not be able to generate a useful debuginfo package.  This would
   render the packages undebuggable with gdb.

 - There's no obvious way to automate the generation of the native
   packages.  This causes the packagecount to more than double, and
   the non-atomic nature of it allows things to get out of sync and,
   for example, break rawhide.

But all this is somewhat tangential to the original point, which was
that "[if] the JPackage repos are added to a FC4 yum configuration,
yum will try to overwrite [Fedora] packages with [JPackage]
packages..."  Allowing the Fedora stack to be extended with JPackage
packages was and is a key requirement.  There's only one way I can see
that would prevent the former while still allowing the latter, and
that's for Fedora's packages to have the same EVR as the JPackage
packages.  Since that is something we cannot commit to, the problem
will remain regardless of where the native code is packaged.

Gary