[Rpm-maint] various bug fixes (patches)

[Panu Matilainen]

On Thu, 15 Nov 2007, Ralf Corsepius wrote:

>
> On Thu, 2007-11-15 at 10:05 +0200, Panu Matilainen wrote:
>> 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:
> [...]
>>> 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
> Erm, no. Implementation should be need/demand driven, not conversely.
>
> Of cause, creating demand by adding features is a common principle of
> marketing ("Only products from brand X have feature Y", ... I guess, I
> am not the only person to have quite a number of gadgets around being
> equipped with some useless ballast "feature Y")

Need IS speculative: is it possible to create (successful) distributions 
without soft dependencies? Obviously it is. The demand for soft 
dependencies in rpm has been there since beginning of times however.

>> 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...
>
> Well, I would expect the same folks starting to complain on
> "Recommends/Suggest" whenever they find a piece of software doesn't work
> because of "missing plugins/add-ons" (Why is X a Recommends and not a
> Requires?") or when trying to mix both strategies ("I need 'plugin X for
> package Y', but don't want to have 'package series Z' installed.").
>
> I.e. I don't see how this feature solves a problem, I feel it is
> shifting around problem (and probably is introducing new ones).

>From rpm POV, we're just adding a couple of optional, informational fields 
to packages. If Fedora doesn't want the extra complexity of dealing with 
them, that's easily accomplished by not using them (disallow use by the 
packaging policies if need be, existence is easy to check automatically 
even) - that's their business. Other large distributions are finding the 
extra information valuable and utilizing it successfully though.

>> 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 :)
>
> OK, then the Mandriva and SuSE folks probably will be able to elaborate
> how they are using it in their distros and their installers.

Pixel already gave some examples of use in Mandriva. One example in SUSE I 
know about is marking language-specific subpackages (eg foo-en, foo-jp, 
foo-de) as supplements of the main package, I'm sure Michael can give more 
use-cases.

 	- Panu -