[Rpm-maint] RPM 4.12.0 alpha released
mls at suse.de
Mon Jul 7 19:00:09 UTC 2014
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 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
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
Michael Schroeder mls at suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
More information about the Rpm-maint