Fwd: MariaDB replacing MySQL

[James Antill]

On Mon, 2013-03-18 at 18:12 +0100, Honza Horak wrote:
> On 03/15/2013 04:22 PM, James Antill wrote:
> > 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?

 Kind of ... the rule is that all idempotent operations should match
packages without caring about case sensitivity. So "yum install Mysql"
doesn't work, but "yum list Mysql" does. 

> > 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?

 Yeh.

> >> 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.

 Right, I see what you mean ... I figured the "swap"/shell was at the
same level as the install/upgrade.

> > 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?

 What I meant is that given your testcase wasn't hitting
compare_providers, and that from what I could see I'd expect
compare_providers to choose MySQL over mariadb the shell case might be
doing a real compare_providers test (and thus. would be what happens if
you upgraded XYZ that depended on a "newer mysql").

> >   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.

 Yeh, with either/both of those changes I'd expect yum to choose mariadb
over the other package ... all other things being equal.