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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
