As alternatives are handled by 'update-alternatives', priority of alternatives are maintained outside of RPM. This gives difficulty to dependency solvers such as urpmi which asks for what dependency to select in cases where there are multiple packages providing a dependency. Currently this is left to user to decide, or if --auto is used, there's no way of instructing urpmi to prefer one package over another to satisfy a dependency, leading to urpmi potentially selecting undesired dependencies. Feeding provides with some priority attribute for the dependency solver to base it's automatic selection on, while used for sorting order of packages presented for user choice is one potential idea..
Changing to "confirmed" because RPM provides
no means whatsoever to choose between two
identical Provides: strings. In fact as "capabilities",
there is no logical sense to the RFE because any
two items that provide identical capabilities are
identical (without additional information to qualify
the decision).
I'm changing the priority to "medium" because the problem
of how to choose between identical Provides: is hardly new
or important. And there is already an existing means to
disambiguate identical Provides: by changing the dependency
strings to something else that is more useful or meaningful.
I've also written a blueprint for using Bloom filters
as an alternative implementation for "attributes".
The difference between an "attribute" and a "priority"
is that priorities can be meaningfully compared (i.e.
mathematically there is a distance metric, and the
underlying assumption is a mapping onto integers
for "priority").
The problem with "priority" is this:
How are the assignments made so that a simple integer comparison
always gives the desired answer?
Maintaining the "priority" ordering just substitutes one maintenance
problem for another; instead an "attribute" attached to an object is
usually simpler to maintain (by inspection) and to use as a logic qualifier
without any need for the mapping onto integers.