On Mon, 2013-03-18 at 18:30 +0100, Honza Horak wrote: > I'd like to discuss the topic about virtual provides in a general > context (not related to MySQL->MariaDB replacement) to find out what > actually is a consensus in Fedora about an issue when "two packages > provide the same (not only) virtual symbol" -- particularly what package > maintainers could/should depend on. > > On 03/15/2013 04:22 PM, James Antill wrote: > > On Wed, 2013-03-13 at 18:08 +0100, Honza Horak wrote: > > > >> >I've spent some time deep in yum and it seems to be better than I > >> >thought now. First, the magic about choosing one provider from more > >> >alternatives is not so dark any more (it was worse few years before) -- > >> >it's actually documented at [1] now. > > It's documented what the current version of yum does, and it's > > documented mostly for information purposes ... if you want to install > > "XYZ" and that is provided by "FOO" and "BAR" then installing either is > > correct (even if it's not what you want). > > > > That's probably how it should work eventually, but I believe we should > also be *sure* what will be installed in case nobody requires either FOO > nor BAR explicitly -- something like distribution-wide default. Doing it as a plugin would be a pretty big fail IMO, doing it in core is fairly simple and we did a PoC a _long_ time ago: http://james.fedorapeople.org/yum/patches/yum-best-providers-metadata.patch ...the main problem was what to do if we committed the patch, how does the data get into the repo. who owns it ... then how do we make it so that spins could have different data (Eg. kdm vs. gdm). It's much like the "app. data" problem, except there was never the huge extra problem of it being a package too ... so if app. data ever gets in, that might show a way for someone to push this data in too (guess you'd want to talk to dnf maintainer though :). My main point was that the above is informational, and while you can use it to game which packages are installed "by default" there are no guarantees that it will remain compatible until the end of time. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
