Fwd: MariaDB replacing MySQL

[Norvald H. Ryeng]

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.

Package conflict is a problem as soon as packages start depending on one  
particular server or tools implementation (e.g., akonadi-mysql). If both  
have the same virtual provide and all packages depend on that instead of a  
specific implementation, they can be conflicting.

>> This would all be solvable if the packages were installable in
>> parallel, which is also the recommended solution [1]. This would
>> require some renaming, but it has several benefits:
>>
>>   - Users can choose to install either MySQL or MariaDB, or both.
>>   - Package maintainers can choose to depend on one or the other.
>>   - Package maintenance becomes easier since the packages don't mess
>>     around with the same filenames.
>>
>> A common virtual provide should solve dependencies for applications
>> that don't care which server they get. With that virtual provide comes
>> the upgrade issues around choosing a default. Could this be solved by
>> bumping the epoch of mariadb-server? Wouldn't that make yum choose the
>> highest versioned package, which would always be mariadb-server? Epoch
>> bumping may not be the prettiest solution, but if it works, we could
>> do:
>>
>>      If existing MySQL users are to be forced over to MariaDB:
>>      mysql*:           virtual provides
>>      mariadb*:         provides mysql*, epoch 1
>>      mysql-community*: provides mysql*, epoch 0 (*)
>>
>>      If existing MySQL users are to remain on MySQL:
>>      real-mysql*:      virtual provides
>>      mariadb*:         provides real-mysql*, epoch 1
>>      mysql*            provides real-mysql*, epoch 0
>
> Interesting idea, we can try that and see if it works, but anyway, I'm  
> not sure if we should rely on it, unless RPM will be consistent and  
> well-defined in that case.
>
> So, Jan (or someone from RPM guys), could this be somehow better than  
> simple "shorter package name wins" or the idea with epoch would still be  
> considered as undefined behavior from RPM POV?
>
>> Using alternatives could also be considered. In any case, the packages
>> have to be installable in parallel.
>
> Sorry for repeating myself -- even if we used alternatives and packages  
> would be installable in parallel -- we still need to say which package  
> is preferred in dependencies. Still the same issue with RPM.

I agree. But it could solve the akonadi-mysql problem. I understand their  
wish to know exactly which server they run, so they could depend on one  
particular server and start it using the unique server name instead of the  
alternatives maintained symlink. Packages that only depend on a  
non-specific server or tools could use the symlinks.

Regards,

Norvald H. Ryeng