On Jul 8, 2008, at 4:40 PM, Alexey Tourbin wrote:
On Mon, Jul 07, 2008 at 09:08:05PM -0400, Jeff Johnson wrote:
From another side, it is not obvious how recursive --needswhat
should
traverse virtual packages where more than one alternative is
available.
Except for multilib (which I personally don't use), what categories
for multiple provides exist?
E.g. executable(foo), or /usr/bin/foo (which can be under
update-alternatives(8) control), or MTA.
There are 3 types of aliasing you have pointed out:
1) Requires: MTA matching Provides: MTA in rpmdb.
Yes, known, there's a handful of these 1-of-N alternatives.
2) Requires: executable(foo) != /usr/bin/foo
There's a form of aliasing here, but it won't matter imho.
The "executable(foo)" is a probe which resolves against the
file system, not an rpmdb. The --whatneeds/--needswhat
display is solely concerned with NVRA mappings from an rpmdb,
not from the file system.
(aside) Yes you can do
Provides: executable(foo)
in an rpmdb. That isn't what the probe was intended for.
There's also the further confusion if/when
Provides: /usr/bin/foo
is present as a dependency, not as a pkg file manifest item.
I consider both of the above Provides: packaging errors personally.
3) Update alternatives
Alternatives is done entirely outside of rpm packaging
with symlink magic, although occaisionally with a Provides: /path/to/
file.
Looking in and Basenames first and Providename index 2nd
is what has usually worked.
The fundamental choice for --whatneeds/--needswhat is whether to
attempt to display all matches or any match or a "preferred" match.
Displaying first-found (or last-found) is enough to give some
"preferred"
meaning to --needswhat/--whatneeds display.
Multilib, which can force choices to packages of same color, generates
far more multiple Provides: than the handful of
Provides: MTA
that are usually around. But multlib usually has a single resolution,
even if
color must be considered too.
All that is needed is criteria for preferring a Provides:. Even for
multilib, there is now %_prefer_color which
can be added to display the "preferred" answer if necessary. Should I
implement?
Note also that the examples I've given for --needswhat/--whatneeds
are slyly/implicitly dependent
on whatever packages are already installed, which is likely to be
whatever was "preferred".
A general answer for "preferred" is more complex however ...
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
