On 03/12/2013 01:14 PM, Norvald H. Ryeng wrote:
On Mon, 11 Mar 2013 19:58:03 +0100, Kevin Kofler
<kevin.kofler@xxxxxxxxx> 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.
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.
(*) The name "MySQL" crashes with the standalone packages at
dev.mysql.com, and I think I read something about a problem with case
sensitive names in one of the mailing list threads. The software is
called "MySQL Community Server", so we suggest the "mysql-community"
prefix. The same prefix is already used by OpenSuSE.
AFAICT at least Bugzilla components are not case-sensitive, which isn't
so important as soon as mysql component actually doesn't exist anymore
in F19 (so bugs at F19 in mysql actually mean bugs in MySQL). But
generally I don't have anything against using mysql-community as a
package name instead of MySQL.
Honza
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
