[Rpm-maint] various bug fixes (patches)
pmatilai at redhat.com
Thu Nov 15 08:05:08 UTC 2007
On Wed, 14 Nov 2007, Ralf Corsepius wrote:
> On Wed, 2007-11-14 at 08:54 -0500, seth vidal wrote:
>> On Wed, 2007-11-14 at 13:42 +0200, Panu Matilainen wrote:
>>> What I'd suggest is:
>>> - take the SUSE approach and store the weak dependencies separately so
>>> supporting weak dependencies from depsolvers etc is entirely an opt-in
>>> thingy and causes no legacy incompatibilities
>>> - ditch out the RPMSENSE_MISSINGOK symbol to signify the fact that we
>>> handle the issue differently (from rpm5)
>>> - replace RPMSENSE_MISSINGOK with RPMSENSE_HINT (only really used
>>> internally at build-time for determining which tag the thing goes to)
>>> - replace (compared to current SUSE patch) RPMSENSE_STRONG with
>>> RPMSENSE_HINT_STRONG to make it obvious what it relates to
>>> (only used when looking at RPMTAG_SUGGEST* RPMTAG_ENHANCE* tags
>>> from headers for classifying "strongness" of the weak dep)
>>> - replace (compared to current SUSE patch) the Requires(strong) spec
>>> syntax variant with Requires(stronghint), again just to make it plain
>>> obvious what it is
>>> Does that sound ok?
>> When do you plan on implementing this and more importantly is there a
>> plan for when it shows up in a fedora release? The packaging committee
>> is going to want a drive by on this, I think.
The plan for rpm.org is to make a new major release (at least a beta) in a
couple of months. Rpm.org gotta get rid of the limitations imposed by
being stuck with dot-dot-dot maintenance releases, and all the work gone
into HEAD needs an outlet.
Fedora issues belong to fedora lists, but putting my Fedora hat on for a
moment: I'll rather hang myself than see another Fedora release go out
with 4.4.2.x ;)
> Also I would like to see some detailed documentation on this feature.
To put it shortly, this "feature" adds a couple of optional, purely
informational tags that applications are free to ignore or use as they see
fit, and query switches to display the information. If eg yum doesn't want
to implement soft dependencies, all you need to do is ... nothing, nothing
at all. The support for optionally installing weak dependencies could be
implemented entirely as a yum plugin.
> Intentionally (non-hostile), devel's advocate questions:
> - Does any application need this feature?
Need is speculative - does any application *need*, say, RPMTAG_URL? It's
nice to have that information though.
> - How are applications supposed to use this feature?
Apps have two options:
a) Ignore (rpm behavior didn't change so this is what happens by default)
b) Apps can query the new tags to see if a package being installed
has any weak deps and offer to install them too. Or just show the
information (ie "you might want to check out these packages too").
To make proper use of soft dependencies, distro/repository level and
depsolver policies are needed. One possible policy / interpretation
- Hard requires are only used for things that applications/libraries
require to run (eg as result of direct linking to a library). These
are always installed.
- Midlevel soft requires ("recommends") are used for things that aren't
strictly needed to run the application (eg dlopened plugins) but
should normally be present. These get installed by default (or in a
gui, they could be checked for installation by default but user can
uncheck any of them) but can always be removed without it being an
- Low priority soft requires ("suggests") are used for things that just
enhance the application/library in some ways that some users may find
useful. Think of it as a hint for the user "since you're
interested in this, you might find these additional pieces useful".
Depsolver might want to offer these for install but not by default
(in a gui, show the packages but unchecked by default)
Enhances and supplements are essentially reverse (soft) requires:
Package A having "Enhances: B" is the equivalent of package B having
"Recommends: A". This is especially useful in situations where you for
whatever reason don't have control over the other package. An example: you
could have "Enhances: flash-plugin" in nspluginwrapper, and when a user
installs the proprietory flash-plugin from Adobe's site, the depsolver
would notice that nspluginwrapper should probably be installed with it (or
at least notify the user about it). Supplements are the same but treated
with same "priority" as suggests.
The average user would probably be quite happy with the above setting. The
people screaming about dependency bloat could turn off installation of any
soft dependencies in depsolver config. And the "I want my
Everything-install!" folks could turn on installation of all soft
Again, the above is just one interpretation of soft dependencies, distros
and depsolvers are free to do whatever they see fit (including ignore)
with the new extra information. Rpm does not enforce *anything* regarding
soft dependencies because, by the very definition, the are *soft*
dependencies and a missing soft dependency can never be an error of any
> ATM, I am not really convinced it is _really_ useful.
Well, in several occasions in my past life, I would've killed to have soft
dependency support in rpm and related tools. And clearly SUSE and
Mandriva are finding it useful (not to mention Debian and derivates :)
- Panu -
More information about the Rpm-maint