how to have yum prefer one dependency over others
Björn Persson
bjorn at xn--rombobjrn-67a.se
Sat Sep 17 13:51:26 UTC 2011
Kevin Kofler wrote:
> The yum default provider picking logic has become so complex (and dependent
> on what the user happens to have already installed!)
[...]
> And while making a decision based on what
> the user has already installed may make sense from a user's perspective,
> from a developer's perspective, it's completely unacceptable because it
> means different users can get different dependencies dragged in by the
> same Requires, even with the same tool!
Do you *actually* mean that you would prefer a package manager that always
chooses the same package regardless of what the user has already installed? If
Gizmo requires frobnicator, which is provided by both Gnome-frobnicator and
KDE-frobnicator, and the user has only installed KDE, do you really want Gizmo
to pull in half of Gnome even though it works fine with KDE? I can't believe
that you would find that acceptable.
But if you actually want that – from a developer's perspective – then it's
dead simple to achieve: Just don't use virtual provides. Write "Requires:
Gnome-frobnicator" in Gizmo.spec. Problem solved; no need to replace the
package manager.
> If we want package maintainers to be able to actually choose what provider
> gets picked by default, all those complex heuristics must be replaced by
> something simple and dependable (e.g. 1. prefer same arch, 2. prever newest
> Provides version, 3. prefer shortest package name, 4. prefer first package
> name in the alphabet, period).
That algorithm would prefer KDE-frobnicator over Gnome-frobnicator, which is
undesired in Gnome-only installations, but it would prefer Gfrobnicator over
Kfrobnicator, which is undesired in KDE-only installations.
Björn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110917/7e97247b/attachment.bin
More information about the devel
mailing list