From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2)
Description of problem:
We have a Java packaging problem that could be solved nicely if rpm
and its dependent tools supported a Suggests: tag.
We want to ship bytecode-only Java packages and supplement them with
packages containing gcj-compiled .sos.
We want to keep the .jars in separate packages from the .sos so that
bytecode-only packages can remain noarch and so that people using a
JIT'ing JVM don't need to download and install the .sos.
If someone installs a bytecode-only package without installing the
corresponding .so package, it will run very slowly. So we'd like to
have yum, upon installing a bytecode-only package, suggest that the
user also install the corresponding .so package.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. try to express a package suggestion in an rpm spec file
as a guy that has to write the dep solver, I _really_
dislike the idea of Suggests.
There is no establish policy for what Suggest would
do on red hat. It also increases the size of the
solution set for a given transaction target
significant. It also introduces the need for
backtracking in the depsolver, which I would
If the packages need the gcj packages in a useful
fashion, they should be a depenency.
Doesn't the RPM port of apt already include Suggests resolution? Can
we use apt as a "policy guide"?
Though the implementation may be difficult, I think Suggests support
would allow for a really nice depsolver usability improvement -- the
ability to express "soft" dependencies.
In the case of these java packages, they *may* require the gcj
packages. It depends on whether the user is running them with a
JIT'ing JVM or not. If they haven't installed a JIT'ing JVM then
they'll want the gcj packages. I'm not sure how to express that using
RPM dependencies without Suggests.
Reassigning to distribution, as this is not an rpm, but rather
a Red Hat, decision. The implementation for a mechanism in rpm is
rather trivial and well known. The consequences are profound,
particularly for depsolvers, and well appreciated by me.
Not my call, mon, nor do I have any wish to lead the almost certainly
spirited and controversial discussion.
No, the semantics of this among the various install mechanisms are
just way too messy.
Perfectly understood and correct decision for Red Hat which
I agree with 110%.
Please note that the mechanism is going in to rpm HEAD no
matter what, as it's easier for me to point to a (known
deficient and complex install policy mechanism) that it
is to continue explaining why rpm does not support
what apt supports.
So rpm HEAD is going to diverge from the rpm-4_3 and older
branches because we agree to disagree regarding the 3 tags
I know of no rpm issues that will be affected by
the setting of RPMSENSE_MISSINGOK in package
content and I will continue to ensure that
the lack of a Suggests: implementation on
the rpm-4_3 branch does not affect installation behavior
by using tracking dependencies and (if necessary) a
packaging version change.