Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040301 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): How reproducible: Always Steps to Reproduce: 1. try to express a package suggestion in an rpm spec file Additional info:
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 rather avoid. 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 Suggests Recommends Enhances 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.