Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
First Last Prev Next    This bug is not in your last search results.
Bug 132763 - rpm should support a Suggests: tag
rpm should support a Suggests: tag
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Bill Nottingham
:
Depends On:
Blocks:
  Show dependency tree / graph
 
Reported: 2004-09-16 15:20 EDT by Thomas Fitzsimmons
Modified: 2014-03-16 22:48 EDT (History)
5 users (show)

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

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

  None (edit)
Description Thomas Fitzsimmons 2004-09-16 15:20:51 EDT 
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:
Comment 1 Adrian Likins 2004-09-16 17:35:22 EDT 
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 18:13:32 EDT 
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 00:12:43 EDT 
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 12:53:22 EDT 
No, the semantics of this among the various install mechanisms are
just way too messy.
Comment 5 Jeff Johnson 2004-09-17 14:41:02 EDT 
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.
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.