DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides

[Radek Holy]

----- Original Message -----
> From: "Kalev Lember" <kalevlember at gmail.com>
> To: "Development discussions related to Fedora" <devel at lists.fedoraproject.org>
> 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).
-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech