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).
> However, in scenarios I tested with packages similar to
> mysql/MySQL/mariadb it turned out, that we never reach the point where
> we have to choose one of more alternate providers. The reason is that
> yum chooses right package before going down to [1] (I tracked the code
> and it never came to the part _compare_providers).
Not sure what operation you tested this with, but you probably missed
something. When installing a virtual provide, the usual code path would
be:
yum install 'mysql(x86-64)' =>
YumBase.install() =>
YumBase.bestPacakgesFromList() =>
YumBase._bestPackageFromList() =>
Depsolve._compare_providers()
> I've tested that on sample packages in one repo, that basically looked
> like this:
>
> mysql-5.5.30
> #last version of the package and also package currently installed
>
> mariadb-5.5.29:
> Provides: mysql = 5.5.29
> Obsoletes: mysql < 5.6
>
> MySQL-5.6.10:
> Provides: mysql = 5.6.10
> # doesn't obsolete mysql
Note that we have two major red flags here:
1. We are mixing a _package name_ "mysql" with a provide "mysql", and
another package name that is different only by capitalization "MySQL".
2. We have multiple providers of "mysql" and an obsolete of
"mysql" (which, again, is based on package name not provides).
...now there are certain parts of yum that will see "FOO" as a package
name before it looks for provides, and thus. will never pick the other
random packages that also provide "FOO", the relevant ones are that is
"yum install" and "yum upgrade" both operate this way.
> The following table shows what actions (cols) yum chose in different
> scenarios -- i.e packages installed (rows):
>
> installed | # yum install mysql | # yum update | # yum shell (*) |
> ------------------------------------------------------------------
> --- | mariadb (**) | --- | MySQL |
> mysql | mariadb | mariadb | MySQL |
> MySQL | mariadb | MySQL | MySQL |
> mariadb | --- | mariadb | MySQL |
>
> (*) "yum shell" is needed in order to install MySQL while removing
> current implementation if any (mysql or mariadb) in one transaction.
It's not obvious what you are doing in "yum shell", but rawhide/F19 yum
also has the swap command (Eg. yum swap MySQL mariadb). But given the
results I wouldn't be shocked if this was the one that represented what
a requires would do.
> (**) The reason why mariadb is chosen is most probably this notice
> printed by yum:
> "Package mysql is obsoleted by mariadb, trying to install
> mariadb-5.5.29-2.fc18.x86_64 instead"
Yes, basically you are hitting:
cmd line "FOO" => package name "FOO"
package name "FOO" => obsoleted by "BAR"
...which doesn't hit compare providers, because there are no providers
to compare.
But if the old package goes away then this won't be the same, or if the
user does "yum install /usr/bin/mysql" (which both the new packages
provide and isn't a package name).
Also when a package "XYZ" requires "FOO", then we don't first lookup a
package with the name "FOO". Instead we just do a general provides
lookup, so that could/would act differently to the above table.
Given that mariadb and MySQL are forks, and will have similar deps. and
be on the same arches etc. ... I'd expect compare providers to come down
to two things:
1. If all the providers give an "= <version>" for the provide, we'll
choose the highest provided version (this is not true in el6 atm. ... if
this is going to happen there). Given the above packaging data, 5.6.x >
5.5.x ... thus. MySQL would be preferred.
2. Shortest name (so MySQL will win).
> This means it works as we'd wish even if we let MySQL packages to
> provide mysql symbols. I'll test the real packages after weekend, since
> I'm going to be off until Sunday.
>
> So, to sum up the above, I've started to believe that we will be able to
> add "Provides: mysql" also to MySQL packages, while mariadb would be
> correctly preferred by default.
I'd bet against this.
> [1] http://yum.baseurl.org/wiki/CompareProviders
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
