On Wed, 13 Mar 2013 18:08:55 +0100, Honza Horak <hhorak@xxxxxxxxxx> wrote:
On 03/13/2013 09:27 AM, Norvald H. Ryeng wrote:
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.
I've spent some time deep in yum and it seems to be better than I
thought now. First, the magic about choosing one provider from more
alternatives is not so dark any more (it was worse few years before) --
it's actually documented at [1] now.
However, in scenarios I tested with packages similar to
mysql/MySQL/mariadb it turned out, that we never reach the point where
we have to choose one of more alternate providers. The reason is that
yum chooses right package before going down to [1] (I tracked the code
and it never came to the part _compare_providers).
Can we get a comment on this from someone with more knowledge of arcane
yum/RPM magic? We need this to be a stable solution, not only luck.
I've tested that on sample packages in one repo, that basically looked
like this:
mysql-5.5.30
#last version of the package and also package currently installed
mariadb-5.5.29:
Provides: mysql = 5.5.29
Obsoletes: mysql < 5.6
MySQL-5.6.10:
Provides: mysql = 5.6.10
# doesn't obsolete mysql
The following table shows what actions (cols) yum chose in different
scenarios -- i.e packages installed (rows):
installed | # yum install mysql | # yum update | # yum shell (*) |
------------------------------------------------------------------
--- | mariadb (**) | --- | MySQL |
mysql | mariadb | mariadb | MySQL |
MySQL | mariadb | MySQL | MySQL |
mariadb | --- | mariadb | MySQL |
(*) "yum shell" is needed in order to install MySQL while removing
current implementation if any (mysql or mariadb) in one transaction.
(**) The reason why mariadb is chosen is most probably this notice
printed by yum:
"Package mysql is obsoleted by mariadb, trying to install
mariadb-5.5.29-2.fc18.x86_64 instead"
We haven't had time to check everything, but we've done some initial
testing and it looks promising.
What we have found, is that MySQL server needs the accompanying mysql and
mysqladmin tools to pass all tests. There is added functionality that
isn't in MariaDB. I suggest mariadb-server depends on mariadb and
mariadb-common, and that mysql-community-server depends on mysql-community
and mysql-community-common. They can both provide the same mysql-server
and mysql symbols (i see no need for the mysql-common virtual provide).
That seems to work in our tests.
This means it works as we'd wish even if we let MySQL packages to
provide mysql symbols. I'll test the real packages after weekend, since
I'm going to be off until Sunday.
Have a nice weekend!
Regards,
Norvald H. Ryeng
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
