On Jun 4, 2007, at 1:07 PM, Patryk Zawadzki wrote:
As you could see on the pld-devel-en list (a topic called "poldek is
dead") there are some problems that seem to be more specific to PLD
than other desktop distros (RHEL or Fedora).
Both RHEL and Fedora have a policy to only ship one-of-a-kind. So you
have one app for inetd, one for foo and one for bar. In PLD you have
all possible appsfor everything and it's left for user to decide.
That raises a couple of corner cases in terms of depsolving. There are
3 flags available to represent external deps - Obsoletes, Requires and
Conflicts. And we have these cases:
1) package X requires Y (simple. just says Requires: Y)
2) package X works better if Y is there (now possible using Requires
(hint))
3) package X is a replacement for no longer available Y (simple.
Obsoletes: Y)
4) package X is an alternative to package Y and only one makes sense
5) package X has nothing to do with Y but both can't be installed
(currently Conflicts)
6) package X has nothing to do with Y but older Y can't run along X
(versioned Conflicts)
Hmmm, the difference between 4) and 5) seems rather small. In both
4) and 5) cases X and Y are mutually exclusive.
The 5) case is traditionally represented with mutual Conflicts:. The
only sense I can make of 4) is that you want to somehow hint that X
is an "alternative" to Y in some weaker sense than 5). There is
Conflicts(hint):
that could be used, but I'm not sure what you are trying to represent.
While 1, 2, 3 seem trivial, there is a problem telling 4, 5, 6 apart.
Currently in PLD case 4 works like this:
foo Requires: smtpserver
bar Provides: smtpserver
bar Obsoletes: baz
baz Provides: smtpserver
baz Obsoletes: bar
While it works for poldek (as it was written to handle such specific
cases) I believe it's broken by design and feel kind of guilty having
to fix such cases.
OK. foo needs bar or baz, not both, and you wish the other to be
automagically
erased.
This issue has been solved in rpm by adding
Obsoletes: smtpserver
to all members of the {baz,bar} mutually exclusive set (with
the meaningless case of a self obsoleting package avoided).
Ideally I'd like 2 more types of Conflicts - Conflicts(similar) that
is weak (not enforced by rpm) and only a hint for a package manager to
possibly uninstall the other package (case 4) and
This sounds like
Conflicts(hint):
rpmlib currently passes unsatisfied dependencies to calling applications
that use the rpmtsCheck() callback (that would be poldek in this
case), but
otherwise ignores the failure. There are return codes from the
callback that
determine how dependency resolution is resumed.
That is the intent, but you are likely the first to try Conflicts
(hint):, caveat emptor.
Conflicts(alternative) that is a regular conflict but with a flag that
tells the package manager to try and resolve that and uninstalling is
a perfectly fine solution (case 5). At least the first one would be
very useful for depsolving in PLD so we can drop the mutual
Provides/Obsoletes hackery as it's a PITA to patch yum, smart and any
other tool to follow our current scheme.
The original problem in rpm with a virtual
Provides: smtpserver
is that each package had to Obsolete: all mutually exclusive
packages. So adding another member to the mutually exclusive
set forced a new Obsoletes: in all other packages.
Now that Obsoletes: will obsolete any package that matches
without sel-obsoleting itself, I believe the problem is already solved
in rpm.
E.g.
Obsoletes: /bin/sh # erases the bash package
Obsoletes: libc.so.6 # erases the glibc package
and the generalization for virtual Provides: is
Obsoletes: smtpserver
erases every other package that has
Provides: smptpserver
But perhaps I miss what you are asking for. Do you have
a concrete example involving actual packages, and a desired goal?
That often helps (me anyways) focus on what problem needs solving.
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
