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
ties.)
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
resolver.
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
transaction.
Cheers,
Michael.
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
