On Tue, 12 Mar 2013 18:25:02 +0100, Honza Horak <hhorak@xxxxxxxxxx> 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@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.
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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
