Björn Persson wrote:
> 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.
The use case I have in mind, which is a real-world case, is this:
phonon Requires: phonon-backend
phonon-backend-* Provides: phonon-backend
phonon-backend-* Requires: phonon
I want any random phonon-backend-* to satisfy the dependency, HOWEVER, I
want installing phonon when it previously wasn't installed to always drag in
phonon-backend-gstreamer, our default backend and the one working the best,
not some random backend which happens to have fewer dependencies. Yum's
convoluted logic is making it basically impossible to do that, and in fact,
on the RPM Fusion builders, phonon-backend-vlc is selected instead, which is
always fun because it means vlc's regular broken dependencies can break
builds of anything KDE-related in RPM Fusion. (I had a k3b-extras-freeworld
build break because of this very issue.) I guess users installing KDE with
RPM Fusion Free enabled will also get the VLC backend by default, which is
not what we want.
We really need a way to be able to specify an explicit default which is used
independently of what the user has installed, even if we don't always use it
(I can see the case of gnome-* vs. kde-*); the version number of the
Provides would be one solution. ("Shortest name" or "first in the alphabet"
is just a hack, which forces silly things like using "phonon-bknd-gst", so I
don't think that's a good way to make the decision, though even that was
better than what we have now, which is almost unpredictable.)
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
