Percona MySQL and MariaDB in EPEL

[Dennis Jacobfeuerborn]

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

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.

Regards,
   Dennis