MySQL-libs conflicts with mariadb-libs-5.5.29-7.fc19.x86_64

Honza Horak hhorak at redhat.com
Mon Mar 11 17:55:28 UTC 2013


On 03/11/2013 12:30 AM, Rex Dieter wrote:
> alekcejk at googlemail.com wrote:
>
>> Last KDE nightly composes failed because of error
>>
>> DEBUG util.py:264:  Error creating Live CD : Failed to build transaction :
>> MySQL-libs conflicts with mariadb-libs-5.5.29-7.fc19.x86_64
>>
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=5100301
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=5100302
>>
>> Previous composes before importing new MySQL package was fine,
>> so last composes problem related  with new MySQL.
>>
>> There is also other problem with missing MySQL component in bugzilla,
>> looks like for bugzilla MySQL=mysql, it finds mysql bugs
>> for MySQL package.
>
> In addition to there not being any MySQL bugzilla component,
>
> 1.  Shouldn't the 'mysql' component be retired and blocked now?

It's done now.

> 2.  Should the "best practice" be to use
> Requires: mariadb, BuildRequires: mariadb-devel
> instead of
> Requires: mysql, BuildRequires: mysql-devel
> now?

mysql and mysql-devel should be still OK, since only mariadb packages 
currently provide these symbols (they became only virtual names).

> 3.  And long-term, what to do about MySQL-libs getting pulled into live
> image composes?  can it be blacklisted or something?

It won't be problem only in case of live image composes, but in 
requiring libmysqlclient.so.18 generally, because RPM simply chooses one 
of the packages providing the same library. It is officially 
un-deterministic (usually it is the shorter one), but we cannot depend 
on it right now.

So to solve the live image composes issue for now I adjusted the major 
soname number to libmysqlclient.so.1018. I know it doesn't solve all the 
issues, though.

Honza


More information about the devel mailing list