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

[Dennis Jacobfeuerborn]

On 12.06.2015 15:25, Radek Holy wrote:
> 
> 
> ----- 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).

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