Fwd: MariaDB replacing MySQL

[Honza Horak]

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.

> This would all be solvable if the packages were installable in
> parallel, which is also the recommended solution [1]. This would
> require some renaming, but it has several benefits:
>
>   - Users can choose to install either MySQL or MariaDB, or both.
>   - Package maintainers can choose to depend on one or the other.
>   - Package maintenance becomes easier since the packages don't mess
>     around with the same filenames.
>
> A common virtual provide should solve dependencies for applications
> that don't care which server they get. With that virtual provide comes
> the upgrade issues around choosing a default. Could this be solved by
> bumping the epoch of mariadb-server? Wouldn't that make yum choose the
> highest versioned package, which would always be mariadb-server? Epoch
> bumping may not be the prettiest solution, but if it works, we could
> do:
>
>      If existing MySQL users are to be forced over to MariaDB:
>      mysql*:           virtual provides
>      mariadb*:         provides mysql*, epoch 1
>      mysql-community*: provides mysql*, epoch 0 (*)
>
>      If existing MySQL users are to remain on MySQL:
>      real-mysql*:      virtual provides
>      mariadb*:         provides real-mysql*, epoch 1
>      mysql*            provides real-mysql*, epoch 0

Interesting idea, we can try that and see if it works, but anyway, I'm 
not sure if we should rely on it, unless RPM will be consistent and 
well-defined in that case.

So, Jan (or someone from RPM guys), could this be somehow better than 
simple "shorter package name wins" or the idea with epoch would still be 
considered as undefined behavior from RPM POV?

> Using alternatives could also be considered. In any case, the packages
> have to be installable in parallel.

Sorry for repeating myself -- even if we used alternatives and packages 
would be installable in parallel -- we still need to say which package 
is preferred in dependencies. Still the same issue with RPM.

> (*) The name "MySQL" crashes with the standalone packages at
> dev.mysql.com, and I think I read something about a problem with case
> sensitive names in one of the mailing list threads. The software is
> called "MySQL Community Server", so we suggest the "mysql-community"
> prefix. The same prefix is already used by OpenSuSE.

AFAICT at least Bugzilla components are not case-sensitive, which isn't 
so important as soon as mysql component actually doesn't exist anymore 
in F19 (so bugs at F19 in mysql actually mean bugs in MySQL). But 
generally I don't have anything against using mysql-community as a 
package name instead of MySQL.

Honza