Bug 132763 - rpm should support a Suggests: tag
Summary: rpm should support a Suggests: tag
Alias: None
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
(Show other bugs)
Version: 3
Hardware: All Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Bill Nottingham
Depends On:
TreeView+ depends on / blocked
Reported: 2004-09-16 19:20 UTC by Thomas Fitzsimmons
Modified: 2014-03-17 02:48 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-17 16:53:22 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Thomas Fitzsimmons 2004-09-16 19:20:51 UTC
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):

How reproducible:

Steps to Reproduce:
1. try to express a package suggestion in an rpm spec file

Additional info:

Comment 1 Adrian Likins 2004-09-16 21:35:22 UTC
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. 

Comment 2 Thomas Fitzsimmons 2004-09-16 22:13:32 UTC
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.

Comment 3 Jeff Johnson 2004-09-17 04:12:43 UTC
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.

Comment 4 Bill Nottingham 2004-09-17 16:53:22 UTC
No, the semantics of this among the various install mechanisms are
just way too messy.

Comment 5 Jeff Johnson 2004-09-17 18:41:02 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.