[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
community.
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.
Thanks!
--Mark
> Cheers,
> Michael.
>
More information about the Rpm-maint
mailing list