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 ...