On 03/15/2013 04:22 PM, James Antill wrote:
On Wed, 2013-03-13 at 18:08 +0100, Honza Horak wrote:
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()
James, thanks for your response. You're right, it does call
_compare_providers() when requesting virtual provide.
<snip>
1. We are mixing a _package name_ "mysql" with a provide "mysql", and
another package name that is different only by capitalization "MySQL".
Now I see it was not the best idea to call it MySQL, but yum sees that
as two different packages, doesn't it?
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.
Understood, we'd have to introduce new virtual provides different than
the former package name, right? However, I don't think it matters in our
case, since mariadb is obsoleting mysql and it should also be the
default, so it will behave as we wish in that case (i.e. mariadb is
chosen by default) -- or do I miss something?
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).
I ran "remove mariadb" and "install MySQL", which is probably what swap
can do.
But given the
results I wouldn't be shocked if this was the one that represented what
a requires would do.
Sorry, I don't get your point here. Can you explain that a bit, please?
<snip>
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).
I see. However, we could do the following adjustments:
1) use epoch in mariadb's "Provides:" (mariadb would win in rule #10 at
[1])
2) change the name of the original MySQL package from MySQL to
community-mysql -- then it should be safe to assume mariadb will be used
before community-mysql. We couldn't use mysql-community because of rule
#9 at [1] -- when some package would require mysql, then mysql-community
would have better prefix and thus would be chosen before mariadb.
So, if we do these two changes and if rules documented in [1] won't
change in the future, we should be able to make yum to choose
un-ambiguously mariadb before community-mysql. Or is there still some issue?
Regards,
Honza
[1] http://yum.baseurl.org/wiki/CompareProviders
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
