Red Hat Bugzilla – Bug 91458
rpm: Should support weak dependencies (suggests/recommends etc.)
Last modified: 2007-04-18 12:53:56 EDT
The thing I miss most in RPM is the lack of having "weak dependencies".
For instance I have the package "foo-bar". Than I'd like to offer the use the
hint that there is
a) the documentation in foo-bar-doc or foo-bar-doc-html etc. which he might
want to install
b) the source available in foo (which happens to create foo-bar*)
c) that there is a nifty GUI to the program foo-bar called fbaroo
The Debian package format DEB has, which comes close to the things I want:
- Package A recommends Package B, if the package maintainer judges that most
users would not want A without also having the functionality provided by B.
- Package A suggests Package B if B contains files that are related to (and
usually enhance) the functionality of A.
Yes, rpm is missing one of Recommends: or Suggests:, I've never
been able to keep straight which is which.
There are two main problems that I (and other rpm maintainers)
have with what you are calling "weak dependencies":
a) "weak dependencies" don't belong in, but rather with, a package.
The problem with putting dependencies hints in a package is
that package metadata starts to rot as soon as you build a package.
This is not a big deal if you can rebuild, but is a huge support
problem for binary-only rpm based distros. So my current answer
is to design a means to associate the weak dependency hints with,
but not in, a package as rpm is missing support for one of the two.
b) establishing well defined and objective semantics for new functionality
in weak dependencies is not exactly clear. When can a suggests and/or
recommends be ignored and when not. Without a clear semantic, I'm hesitant
to undertake the clarification necessary. Clearly rpm has survived this
long without either recommends and suggests.
Deferred until somewhen for an omplementation with, but not in, a package.
> "weak dependencies" don't belong in, but rather with, a package.
For recommended additionally packages I agree, but for
package -> package-devel
package -> package-docs
package-docs -> package
package* -> package.src.rpm
it makes sense to put it into the rpm. After all in 99% of the cases they are
produced by the same .spec file.
For the other relations (GUI etc.) I agree that storing them externally is
probably a better idea.
Again, I don't disagree. What is really missing
in rpm based distros is the administrative controls
necessary to force the perfectly sensible (and even defacto pragma)
consensus on the dependencies you mention above.
Without consensus, only rock'n'roll is possible. Oh well ...