Fwd: MariaDB replacing MySQL

[Jan Zelený]

On 14. 3. 2013 at 16:44:58, Norvald H. Ryeng wrote:
> 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.

CCing James and Zdenek, as they are *the guys* when it comes to yum depsolver 
magic.

Jan

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