----- Original Message ----- > From: "Dennis Jacobfeuerborn" <dennisml@xxxxxxxxxxxx> > To: devel@xxxxxxxxxxxxxxxxxxxxxxx > Sent: Saturday, June 13, 2015 12:30:39 PM > Subject: Re: DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides > > On 12.06.2015 15:25, Radek Holy wrote: > > > > > > ----- Original Message ----- > >> From: "Kalev Lember" <kalevlember@xxxxxxxxx> > >> To: "Development discussions related to Fedora" > >> <devel@xxxxxxxxxxxxxxxxxxxxxxx> > >> Sent: Friday, June 12, 2015 3:09:50 PM > >> Subject: Re: DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides > >> > >> On 06/12/2015 10:28 AM, Radek Holy wrote: > >>> If a package "Requires: foo" and both "bar" and "barbaz" "Provides: > >>> foo", they are handled as being equally suitable. DNF/libsolv is not > >>> going to prefer packages with shorter names. > >> > >> Yes, very much agreed here. Please don't add the yum shortest name hack > >> to DNF. This and the rest of the depsolving quirks that choose one > >> provider over the other depending on what else happens to be installed, > >> have made my life quite hard over the years :) > >> > >> Let me try to elaborate. > >> > >> The issue I've had with yum's virtual provider depsolving is that there > >> is currently no way to set a default. A default where it would by > >> default install the package that the maintainer has chosen, but would > >> also allow swapping it out if the user needs to. > >> > >> An example here would be an app that has two backends. One of those > >> backends would be the preferred backend and other one experimantel, and > >> maybe a third one that is for a special use case backend that isn't > >> interesting for the general audience. The way to express this with rpm > >> deps would be to have a virtual provide that all of the backends > >> packages provide, so that the user could choose which one to install. > >> > >> An example here would be PackageKit with different backends. It used to > >> have 2 backends, PackageKit-hawkey and PackageKit-yum (we dropped the > >> different backends from Fedora now, but it was a valid issue in last > >> release). Both of them would have a common virtual provide that > >> PackageKit itself would depend on, to make sure at least one of the > >> backends is installed. > >> > >> With the yum system, yum would pretty much always just pick the shortest > >> name. It _happened_ to be PackageKit-yum, but that was totally an > >> accident. And it made it impossible to change the default without > >> renaming the packages - so in a new release that was supposed to use > >> hawkey, we'd have very little options besides renaming PackageKit-hawkey > >> to PackageKit-h for example to make sure it wins over -yum. > >> > >> What I feel would be a good solution to the problem above would be to > >> have a way to specify the default. I believe this problem is already > >> solved in apt-get with a very nice syntax: the OR syntax: > >> > >> Requires: PackageKit-hawkey | PackageKit-backend > >> > >> ... where PackageKit-backend is a virtual provide that both of the > >> backends satisfy. > >> > >> With the requires above, any of the two would solve the requires, but > >> dnf could use the information to choose the first one as the default > >> when it doesn't have any of the backends already installed. > >> > >> -- > >> Kalev > > > > I'd just add that there are multiple sources of preferences. The package > > maintainer may prefer something else than the user and both of them may > > prefer something else than the distribution. E.g. it was said to me the > > Fedora prefers "mariadb" over "community-mysql". This cannot be solved on > > the package level. "mariadb" maintainers use one of these YUM hacks to > > achieve their goal but we'd like to find a correct solution (or make the > > hack an official Fedora guideline). > > The preferences of the package maintainer and the distribution is really > a policy issue and can't be solved on the technical level. The package > maintainer should select his preference and if the distribution has > other ideas then they can contact the maintainer and hash out a solution. > > What does need to be solved technically though is how that preference is > expressed in the package and I'm wondering if the Recommends/Suggests > mechanism can be used for this. > The package adds a Require for the virtual provide but also a Suggest > for one explicit package that fulfills that dependency. The dependency > to install is then selected as follows: > > If a package that satisfies the virtual provide is already installed > then everything is ok so just install the package. > If a package that satisfies the virtual provide is installed together > with the dependent package then use that to satisfy the dependency and > everything is fine as well. > Lastly if no package from the system or the command line satisfies the > virtual requirement chose the one that is suggested by the dependent > package. > > That way the default would be explicitly expressed by the > maintainer/distribution but the user can easily override this by already > having a fitting package installed or by providing one explicitly on the > command line during installation. > > Regards, > Dennis Well, my point was that e.g. in case of MySQL, there is a number of packages that require MySQL. If Fedora prefers "mariadb" and you insist on expressing this preference on package level, Fedora has to put this "weak dependency" in every package that requires MySQL. Or at least in one of them and make sure that there is no package (even in the third party repos) that "Recommends/Suggests" "community-mysql" and that the package will always be installed on every device that will ever install MySQL. That's why I think that the problem cannot be solved (systematically) on the package level (at least using weak dependencies). -- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
