[Rpm-maint] various bug fixes (patches)

[Panu Matilainen]

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.
> Agreed.

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 
example:

- 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
   error.
- 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 
dependencies...

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 
kind.

> 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 -