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.
_______________________________________________
Rpm-maint mailing list
[email protected]
http://lists.rpm.org/mailman/listinfo/rpm-maint
