Software Management call for RFEs
awilliam at redhat.com
Fri May 24 17:09:54 UTC 2013
On Thu, 2013-05-23 at 15:36 -0300, Paulo César Pereira de Andrade wrote:
> 2013/5/22 Björn Persson <bjorn at xn--rombobjrn-67a.se>:
> > Jan Zelený wrote:
> >> what are the changes that you would like to see in the foreseeable
> >> future (say 2-3 years) and why would you like to see them (what would they
> >> help you with)?
> > Dare I say ... (puts on a helmet) ... Recommends and Suggests?
> > We really should have a way for Yum and Packagekit to say "Hey, if
> > you're installing that, maybe you also want this?". A -devel package
> > and its corresponding -doc package should recommend each other for
> > example. They shouldn't require each other, because then they could
> > just as well be the same package, but usually you want to install them
> > together and it would be helpful to at least notify users who install
> > the -devel package that the -doc package also exists.
> > Another example is a database server and its command line client, which
> > you often but not always want to install together. The server should
> > recommend the client, while the client might only suggest the server.
> > A third example is graphical administration tools for some daemon that
> > are in a separate package so that the daemon can be installed without
> > pulling in half a desktop environment. In this case the daemon should
> > suggest the tools, but perhaps not recommend them.
> The only few times I used Suggests (in Mandriva) was to "suggest"
> optional, but better experience/functionality if installed, packages in
> non-free, but I think I never fully understood what it is supposed to
> mean, just that it is a Requires that does not break dependencies.
Usually softer dependencies don't have a single specific 'meaning'
exactly. Even Requires doesn't _quite_, because you can override
Requires with rpm --nodeps .
It's more useful (I've found, anyway) to think of this as metadata that
it's the package manager's responsibility to interpret, and that you
take all the possible ways the package manager can interpret that
metadata into account when you create it.
Usually, package managers are configurable to do various things with
soft dependencies. IIRC, Mandriva was configured to install the soft
dependencies of packages by default. However, you could then remove them
without the 'requiring' package being removed. So if foo Suggests: bar,
'urpmi foo' would install bar, but 'urpme bar' would not require the
removal of foo.
However, you could configure urpmi not to install Suggested packages, if
you wanted to keep a very minimal system.
So the semantics of Mandriva's system are fairly simple, and the
executive takeaway for a packager is pretty simple too: use Suggests:
for things that a package doesn't strictly require to work, but which
might make the experience of using it better for many people.
With a more complex three-level system like Debian's there are likely to
be more configuration options for the package manager's behaviour with
regards to each form of dependency, and hence more possible semantics,
but again once you understand the various 'supported' options for how to
handle the different types of dependency at the package manager level,
you should be able to understand which form of dependency to express in
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
More information about the devel