[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rpmorg-maint
Subject:    [Rpm-maint] RPM 4.12.0 alpha released
From:       mark.hatle () windriver ! com (Mark Hatle)
Date:       2014-07-09 16:04:41
Message-ID: 53BD6819.8000608 () windriver ! com
[Download RAW message or body]

On 7/7/14, 2:00 PM, Michael Schroeder wrote:
> 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 use both RPM and Smart for dep solving.  Smart for the download and rpm for 
the ordering of the install.

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

Yes, but then the expectation is that 'B' isn't configured in.  It's a somewhat 
(intentionally) rare case, but it does happen.

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

The way they are stored is semantics, but I certainly prefer the deps be stored 
with the normal requires.

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

Using both mechanisms is reasonable to me.  As long as there is a way to migrate 
from tag to missingok and missingok to tag for various purposes, it should be 
fine.  (Even if this isn't internal to RPM, but in the createrepo [or similar] 
used by the various resolvers.)

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


[prev in list] [next in list] [prev in thread] [next in thread]