James Antill wrote:
> ¹ There are ways to game it, if needed ... but that will likely involve
> pain for someone.
There are at least 2 very simple ways to game this system. Imagine we would
like to make kdebase-runtime the default notification daemon. (We actually
don't. It's just an example to prove my point.) Then consider those 2 cases:
1. The -deps metapackage. For example, if we were to set up things this way:
kdebase-runtime Provides: desktop-notification-daemon
kdebase-runtime Requires: kdebase-runtime-deps
All other Requires of kdebase-runtime are filtered.
kdebase-runtime-deps Requires "38 things".
kdebase-runtime-deps is otherwise empty.
then kdebase-runtime would win. (This scenario is more or less present
already in your commit message.)
2. The provider metapackage. This one is even simpler to put into act
because it doesn't require mucking with autoreqs. For example, consider this
scenario:
kdebase-runtime-nd Provides: desktop-notification-daemon
kdebase-runtime-nd Requires: kdebase-runtime
kdebase-runtime-nd is otherwise empty.
kdebase-runtime Requires "38 things".
then kdebase-runtime-nd would "win" and drag in kdebase-runtime.
I think yum is trying to become too smart with all those complex and fragile
heuristics. Back when it was always "shortest name", what happened, even if
sometimes suboptimal, was at least predictable!
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
