[Rpm-maint] RPM 4.12.0 alpha released

[Michael Schroeder]

On Mon, Jul 07, 2014 at 12:11:51PM -0500, Mark Hatle wrote:
>> RPMSENSE_MISSINGIOK is a hack and storing Enhances with the Provides
>> dependencies makes no sense at all. It's much cleaner to use different
>> tags instead of trying to force them into existing tags. And we need
>> to support four groups (Suggests,Recommends,Enhances,Supplements).
>
> I'm not concerned with enhances.  As far as I know tell enhances really is 
> a no-op when it comes to dep solving.

It has a bigger brother called 'Supplements' which is used in depsolving.
(Actually Enhances is kind of used, our depsolver uses it to break
ties.)

>> The dep solver (i.e. the application on top of rpm) mostly uses
>> repository metadata and thus does not care much about where the
>> deps are stored inside rpm.
>>
>> Rpm itself uses dependencies both for verification and ordering
>> purposes. For verification, the dependencies are not needed at all,
>> as they can always be broken. Thus ordering remains. We (SUSE)
>> currently ignore weak deps in the ordering step, and I don't know
>> of any ordering issue (we have them since 2006).
>
> We (the Yocto Project) -do- use dependencies and produce and use packages 
> with the MISSINGOK meta data.

Sure, but do you really use rpm for depsolving? Or do you use something
else like yum/zypper/smart? The real handling of MISSINGKOK is not
in rpm, but in the program on top of rpm.

> We DO need the ordering because if the 
> ordering is not resolved and package 'A' "suggests" package 'B'.. but 
> package 'B' is installed later, the post install scripts may run before 
> 'B'... which means we'll get a potentially incorrect result.

But "suggests" can be broken, so it's perfectly legal to first install
A without B and then in a second transaction install B. The end result
must be the same.

> I really don't one way as to the name suggests vs recommends.. what I do 
> care about is that whichever name is used as the "install this by default 
> if available" (recommended in debian language) is using MISSINGOK, and is 
> being resolved in the dependencies.

I think you mean that MISSINGOK is used *and* the deps are stored with
the normal requires, right? 

> I don't want to introduce additional processing and compatibility issues as 
> MISSINGOK is already implemented and being used by a part of the overall 
> RPM community.

The SUSE way is also implemented (since 8 years) and being used by a
part of the overall RPM cummunity.

> As for SuSE compatibility, if the non-missing ok is heavily used -- then I 
> strongly suggest that we work to enable RPM to know of both mechanisms, and 
> at least internally promote that tag to a 'MISSINGOK' status for the 
> resolver.

That's easy as rpm ignores the weak deps stored in the tags. And
at least the SUSE rpm ignores MISSINGOK deps when verifying a
transaction.

Cheers,
  Michael.

-- 
Michael Schroeder                                   mls at suse.de
SUSE LINUX Products GmbH,  GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}