Fwd: MariaDB replacing MySQL

[Norvald H. Ryeng]

On Wed, 13 Mar 2013 18:08:55 +0100, Honza Horak <hhorak at redhat.com> wrote:

> On 03/13/2013 09:27 AM, Norvald H. Ryeng wrote:
>> On Tue, 12 Mar 2013 18:25:02 +0100, Honza Horak <hhorak at redhat.com>  
>> wrote:
>>
>>> On 03/12/2013 01:14 PM, Norvald H. Ryeng wrote:
>>>> On Mon, 11 Mar 2013 19:58:03 +0100, Kevin Kofler
>>>> <kevin.kofler at chello.at> wrote:
>>>>
>>>>> Honza Horak wrote:
>>>>>> This doesn't solve all the issues -- if package like akonadi-mysql
>>>>>> says
>>>>>> "Requires: mysql-server", then Oracle MySQL either wouldn't satisfy
>>>>>> that
>>>>>> requirement or (in case it includes "Provides: mysql-server") RPM
>>>>>> choosing behavior would be ambiguous.
>>>>>
>>>>> And it should not satisfy it.
>>>>>
>>>>> We now changed the Requires in akonadi-mysql to mariadb-server to be
>>>>> sure of what we get.
>>>>
>>>> This dependency is a problem. It makes it impossible to install
>>>> MySQL-server on a KDE system since mariadb-server and MySQL-server
>>>> conflict.
>>>
>>> I don't think conflict is actually the main problem -- the inability
>>> of RPM to un-ambigously choose one of the two packages that provide
>>> the same symbol *is* the real problem. If we solved that one,
>>> MySQL-server could provide right symbol and KDE system would be happy.
>>
>> I fully agree that enforcing the default is the main problem. It makes
>> the whole ting very difficult.
>
> 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.
>
> 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).

Can we get a comment on this from someone with more knowledge of arcane  
yum/RPM magic? We need this to be a stable solution, not only luck.

> 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
>
> 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.
>
> (**) 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"

We haven't had time to check everything, but we've done some initial  
testing and it looks promising.

What we have found, is that MySQL server needs the accompanying mysql and  
mysqladmin tools to pass all tests. There is added functionality that  
isn't in MariaDB. I suggest mariadb-server depends on mariadb and  
mariadb-common, and that mysql-community-server depends on mysql-community  
and mysql-community-common. They can both provide the same mysql-server  
and mysql symbols (i see no need for the mysql-common virtual provide).  
That seems to work in our tests.

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

Have a nice weekend!

Regards,

Norvald H. Ryeng