[Rpm-maint] RPM 4.12.0 alpha released
mark.hatle at windriver.com
Wed Jul 9 16:04:41 UTC 2014
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
>>> 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
> 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
More information about the Rpm-maint