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 and maybe 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 ...