[Rpm-maint] various bug fixes (patches)

[Panu Matilainen]

On Tue, 13 Nov 2007, Michael Schroeder wrote:

> On Tue, Nov 13, 2007 at 02:50:36PM +0200, Panu Matilainen wrote:
>> Actually my main beef with the Suse implementation is really just a naming
>> issue about the flags:
>> +    { "hint",          RPMSENSE_MISSINGOK },
>> +    { "strong",                RPMSENSE_STRONG },
>> ...
>> +       tagflags = RPMSENSE_MISSINGOK;
>> +       if (macro && (!strcmp(macro, "recommends") || !strcmp(macro,
>> "buildrecommends")))
>> +           tagflags |= RPMSENSE_STRONG;
>>
>> "This is a strong missingok" just .. spells odd to me. I'd rather have
>> something like RPMSENSE_HINT (which is treated as "missing ok") and
>> RPMSENSE_HINT_STRONG (and "stronghint" for the spec visible part) or
>> something to that effect. Better suggestions (no pun inteded :) are most
>> welcome.
>
> You don't need the missingok flag for SUSE's weak dependencies
> at all, as they are not stored in the normal dependency tags.
>
> If you want to add weak deps you need to decide where to store them.
> There are two possibilities:
>
> 1) Jeff's way:
>
>   Put suggests into the require dependencies and enhances into
>   the provides dependencies. Use the RPMSENSE_MISSINGOK flag
>   to tell them apart from normal dependencies.
>
>   Advantage:
>     - compatible to rpm-5
>     - can do reverse lookups with '--whatprovides' and
>       'whatrequires' (this might also be a disadvantage,
>        as you currently can't exclude weak deps from
>        the searches)
>   Disadvantages:
>     - breaks with older rpm versions and installers
>     - storing enhances as provides is a bit odd
>
> 2) SUSE's way:
>
>   Put suggests and enhances in the corresponding tags (they
>   already exist in rpm-4, but where not used)
>
>   Advantage:
>     - old rpm versions and installers just ignore them
>   Disadvantage:
>     - incompatible with rpm-5
>     - there's currently no index for reverse lookups

The SUSE way is opt-in, whereas JBJ way is opt-out... in the extremely 
conservative world of RPM I think opt-in is the better way to go. We're 
incompatible with rpm5 anyway, so that aspect doesn't mean much here.

Also while storing weak requires along with regular hard requires would 
kindof make sense, mixing enhances with provides is, like you said, 
somewhat odd. Enhances are more like reverse requires, very little to do 
with provides. Better to store them separately anyway.

Everybody here seems to agree with this (so far, knock wood), a pleasant 
surprise :)

> Adding a semi-weak version (i.e. recommends/supplements) with
> RPMSENSE_STRONG is a different (and minor) issue.

Yes, and I've no problem with the semi-weak thingie (on the contrary). All 
that I object to is the symbol names used, which is indeed a minor detail 
in the big picture.

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?

 	- Panu -