[Rpm-maint] RPM 4.12.0 alpha released

Mark Hatle mark.hatle at windriver.com
Mon Jul 7 17:11:51 UTC 2014

On 7/4/14, 4:34 AM, Michael Schroeder wrote:
> On Thu, Jul 03, 2014 at 03:17:22PM -0500, Mark Hatle wrote:
>> On 6/27/14, 9:41 AM, Panu Matilainen wrote:
>>> - Support for weak dependency tags (suggests, recommends etc)
>> I finally got a chance to look at this, and I'm a bit concerned with what is there.
>> The 'SUGGESTS' and 'ENHANCES' combo should be using the Requires/Provides
>> with the RPMSENSE_MISSINGOK.  This way they are ignored when not available,
>> but directly affect the installer ordering during dependency resolution.
> 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.

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

>> I know the complaint in the past is third party tools don't know how to
>> process MISSINGOK.  (IMHO that's a bug in the external tools, they should
>> be updated.) One alternative could be to use the new weak dependency tags
>> and 'adapt' them to the MISSINGOK internally so that the dep solver could
>> continue to work as it has.  (It still causes some issues for me with the
>> actual package contents/format though.)
>> Note: rpm 'suggests' had previously been implemented to work the same way
>> that 'recommends' was implemented in Debian.. so the swap in names may be a
>> bit confusing -- but the purpose is that this is something that should be
>> installed if available, but not fail.
>> the other, 'recommends', was something that was added to work like
>> 'suggests' from Debian.  It's just suggested to the user, but does affect
>> the install in any way.
> As said, SUSE uses suggests/recommends since 2006 in a Debian
> compatible way, it makes no sense to use to swap them.

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

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.

I'm not against using both mechanism (TAG and/or MISSINGOK) within the packages 
themselves, but the resolver is key concern.. and I have a large install base 
where I need to continue to support MISSINGOK.


> Cheers,
>    Michael.

More information about the Rpm-maint mailing list