MariaDB: Packagers needed

[Honza Horak]

On 10/29/2012 04:36 AM, Sven Lankes wrote:
> On Sun, Oct 28, 2012 at 11:31:25PM +0100, Kevin Kofler wrote:
>
>> Uh, conflicting with MySQL is really a no go (just look at how many things
>> require mysql-libs, and even mysql-server is required for Akonadi, and
>> mysql-embedded or Amarok), why isn't the fork renaming its stuff? If the
>> idea is to be a 100% compatible drop-in replacement, then Fedora needs to
>> make a choice whether to ship Oracle's MySQL or MariaDB and then stick to
>> it.
>
> That may be the outcome of all of this. But that still means that we need
> MariaDB packaged first.

On the one hand we could first prepare mariadb package (package review 
is frozen for a while, but I'll try to push that forward soon), but on 
the other hand we should know how we want to ship it -- and package it 
according to that.

This is why I'd like to refresh this topic, which froze too in a state 
with no resolution (at least I haven't noticed any).

What I'd like to achieve is to collect real risks (or pros & cons) of 
all possible solutions. Right now I see these options:

1. continue shipping only mysql
2. ship mysql + mariadb, that would conflict
3. ship mysql + mariadb with adjusted file-names and using alternatives
4. ship mysql + mariadb with adjusted file-names but not using alternatives
5. drop mysql and ship only mariadb
6. is there any other?

The following are notes I tried to summarized mainly from the thread 
started at
http://lists.fedoraproject.org/pipermail/devel/2012-October/173089.html
(+ some of my POVs)

ad 1. continue shipping only mysql:

PROS:
* Admins would be happy (unless they care about early security updates, 
fixes and regression tests -- so probably not happy that much)

CONS:
* No early (not only) security fixes
* No new regression tests
* It doesn't seem to me mysql upstream will ever become more open, the 
opposite is much more probable.

NOTE: Considering just changes made by Oracle during the last year made 
on mysql project I'd say we should only think about *how* and *when* 
switching to an alternative, not *if* anymore.


ad 2. ship mysql + mariadb, that would conflict:

PROS:
* Probably the easiest way to do at least in the beginning.

CONS:
* It would require twice much work to maintain two packages.
* What message would we send to users - that we don't know what we want?
* In a long term it doesn't look sustainable.

NOTE: It could be used in a transient period, e.g. during one release.


ad 3. ship mysql + mariadb with adjusted file-names and using alternatives

PROS:
* To give an option to admins? I'm not really sure if this is even good.

CONS:
* cons from 2. apply here
* I don't think this is actually possible. Alternatives work fine with 
commands, but I haven't seen a usage of this tool for libraries and 
directories.
* That would also require 100% API/ABI compatibility of libraries, which 
we can't depend on.


4. ship mysql + mariadb with adjusted file-names but not using alternatives

PROS:
* We could provide both packages at the same time without conflicts

CONS:
* cons from 2. apply here
* We don't want to differ from upstream
* What package depended packages would be built against?


ad 5: drop mysql and ship only mariadb

PROS:
* We'll provide a package with active and open upstream, that cares 
about (not only) security bugs...
* Some enhancements in comparison to mysql

CONS:
* Transition could be harder, we would have to take this like a rebase 
(we probably can't depend on 100% API/ABI compatibility).
* Admins would have to migrate.

NOTES: Similar will happen soon or later (at a time of rebasing to 
mysql-5.6).
Right now my favorite one.

So what have I said wrong/omitted?

Regards,
Honza