raising Yum's IQ (was: Re: [fedora-java] Re: Fedora Core 5 Wishlist)

[Vadim Nasardinov]

On Friday 16 September 2005 07:24, Gary Benson wrote:
> 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 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.

Yum can be changed to have a way to associate the native packages with
the bytecode ones.

>  - 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.

Yum can be changed to handle this.

>  - 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.

Can you elaborate?  I thought native compilation worked by taking
.class files as input.  Where do the sources come in?  Secondly, why
can't you build native packages from the same SRPM that the binary
non-native RPMs were built from?  I don't believe this has been
discussed on this list in sufficient detail.

>  - 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.

IIRC, David suggested repeatedly that JPackage would be more than
happy to accept .spec files where native compilation logic was present
conditionally and was off by default.  I seem to recall vaguely this
suggestion getting dismissed as impractical but don't remember any
detailed explanation of why this may not be feasible.

The bottom line is, although the current situation is the best
solution we could think of, it is not a good solution.  The fact of
the matter remains that Fedora and JPackage repositories don't mesh
very well at this time.  In view of this, why don't we explore the
option of adding explicit knowledge of the Java packaging situation to
Yum?  If this turns out to be a dead-end, fine.  At the very least, we
will have explained, in a public forum, why smarter Yum is not the
answer.