Percona MySQL and MariaDB in EPEL

[Marian Marinov]

On Tuesday 21 June 2011 00:43:30 Marian Marinov wrote:
> On Monday 20 June 2011 22:40:48 Dennis Jacobfeuerborn wrote:
> > On 06/20/2011 08:31 PM, Kevin Fenzi wrote:
> > > On Mon, 20 Jun 2011 21:11:17 +0300
> > > 
> > > Marian Marinov<mm at yuhu.biz>  wrote:
> > >> I have thought about building both MySQL packages as a separate
> > >> daemons but the problem is that since they are one and the same, they
> > >> use the same port ,the same configuration files and the same data
> > >> directories.
> > >> 
> > >> Althou that could be changed with a few simple patches this would
> > >> make them somewhat cripled.
> > >> Also the userland tools use the same configuration files (~/.my.cnf)
> > >> which will complicate things even more.
> > >> 
> > >> Is it possible for the EPEL policy to bend a little here for at least
> > >> one of these packages ?
> > > 
> > > I suppose these could fall under the compatibility packages thing we
> > > have been talking about for things like newer boost or the like.
> > > 
> > > http://fedoraproject.org/wiki/Packaging:Conflicts#Compat_Package_Confli
> > > ct s
> > > 
> > > I think we are drving down a slippery slope here tho.
> > > A downside of this kind of thing also is packages or people who do 'yum
> > > install /usr/bin/mysqld'. They aren't really sure what they will get
> > > there.
> 
> I agree here, when the exceptions become too many then they start to
> overrule the policy.
> 
> > That doesn't look like much of a problem though. If you need something
> > specific then you should install something specific. If on the other hand
> > "anything that provides /usr/bin/mysqld" is good enough then you can't
> > really complain.
> > 
> > > I wonder if this wouldn't be better in IUS?
> > > 
> > > Or talk with upstream about renaming things so it can parallel install,
> > > and then perhaps we could change packages to need 'mysql-database' or
> > > something that could get added as a virtual provides to all of these?
> > 
> > The question is if the other upstreams consider themselves to be
> > alternative implementations of MySQL and pledge to uphold compatibility
> > or if they consider themselves to be forks of the original project. If
> > it's the latter then they should live in their own space and change
> > names of binaries, paths, etc. the same way drizzle did. If they are
> > simply alternative implementations though this would probably have to be
> > resolved using proper conflicts/provides in the rpm's.
> 
> For MariaDB I'll talk with the developers since at some point in time(soon)
> they will be completely different then MySQL(they already did a few
> renameings). And this may make them uncompatible with MySQL.

Ok this statement is wrong. I have just been convinced by the MariaDB devs, 
that MariaDB will remain 100% compatible with the file formats of Oracle's 
MySQL which automatily joins it with Percona. It is in the same situation. 
MariaDB roadmap will introduce new storage engines and better query optimizer, 
but everything that is myisam and innodb will be 100% compatible.


> 
> For Percona however, this is not the case. They use the sources provided by
> Oracle and simply add the Google patches and their own engine patches. They
> don't change anything else, which makes them a drop in replacement for
> MySQL with a future plans to stay that way.
> 
> Regards,
> Marian
> 
> > Regards,
> > 
> >    Dennis

-- 
Best regards,
Marian Marinov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20110621/458047c6/attachment.sig>