"When I asked you to repost with just a link, I didn't mean also attach the orig email with the 20k spec file that was the reason the mail was too long in the first place."
maybe you should make clearer what you want if you force people to search in their archives because add the SPEC was a niceness from me to explain the rest of my post - my "mariadb.spec" is much smaller as many posts
The moderator gave the following reason for rejecting your request: "Can you file a bug with your suggested mysql improvements, and/or repost this with just a link to your spec. Thanks"
my post contained the SPEC-file which is plaintext and the sources and patches are the same as in the MariaDB src.rpm from koji, and as i said there are a lot of changes besides the Obsoltes/Provides which are far away from fedora guidelines
but however http://access.thelounge.net/harry/mariadb-5.5.29-18.fc18.20130309.rh.src.rpm
the point is: INSTALL "mysql-oracle" under /usr/local and replace/obsolete mysql and all subpackages completly with it and the whole discussion would be done long ago and all the maintaining troubles over the release avoided
-------- Original-Nachricht -------- Betreff: Re: MariaDB replacing MySQL Datum: Sat, 09 Mar 2013 17:14:57 +0100 Von: Reindl Harald h.reindl@thelounge.net Organisation: the lounge interactive design An: Development discussions related to Fedora devel@lists.fedoraproject.org
Am 08.03.2013 08:09, schrieb Rahul Sundaram:
On 03/06/2013 08:44 AM, Miloslav Trmač wrote:
File conflicts within the server packages might still be a concern, I don't know. Per the decision quoted above, FESCo would prefer the maintainers of the two servers to agree on a solution.
If the maintainers don't reach a solution or if one of them finds the current proposal unsatisfactory, file a ticket at
and why in the world is this not solved more pragmatically?
my conslusion is * MariaDB will replace mysql as default * any package will be linked against mariadb * Oracle MySQL should only provide the server and not the client-tools
so why is MariaDB not obsoleting mysql without all this versioning tricks and "mysql-oracle" installs the server under "/usr/local/mysql-oracle/" and provides a "mysql-oracle.service"?
the complete packaging would be so much easier like with my own SPEC-file which works fine for F18, yes i know there are a lot of things we do not need removed but take it as sample how a migration could work because it also replaces mysql-5.5.30 while it's own version is 5.5.29
On Sat, 09 Mar 2013 19:20:08 +0100 Reindl Harald h.reindl@thelounge.net wrote:
"When I asked you to repost with just a link, I didn't mean also attach the orig email with the 20k spec file that was the reason the mail was too long in the first place."
maybe you should make clearer what you want if you force people to search in their archives because add the SPEC was a niceness from me to explain the rest of my post - my "mariadb.spec" is much smaller as many posts
To be clear, this was me, in my role as moderator of this list.
I just don't think every subscriber on this list wants a copy of your mariadb spec when interested people can just follow a link to it.
The moderator gave the following reason for rejecting your request: "Can you file a bug with your suggested mysql improvements, and/or repost this with just a link to your spec. Thanks"
my post contained the SPEC-file which is plaintext and the sources and patches are the same as in the MariaDB src.rpm from koji, and as i said there are a lot of changes besides the Obsoltes/Provides which are far away from fedora guidelines
Right. I suggest you file a bug and note your specific improvements for the mariadb maintainers. They can evaluate them, there's no reason it needs to be on the list.
kevin
Am 09.03.2013 19:43, schrieb Kevin Fenzi:
To be clear, this was me, in my role as moderator of this list.
I just don't think every subscriber on this list wants a copy of your mariadb spec when interested people can just follow a link to it
maybe you have a bad day
431 lines plaintext at the bottom of a plain-text message forces nobody to scroll down if he is not interested and is shorter as most messages to the topic in summary for a non well planned feature
you only punsihed me to upload a file on a public server with no win
Right. I suggest you file a bug and note your specific improvements for the mariadb maintainers.
this is nothing for the mariadb maintainers
having "mysql-oracle" and only the server in a non-collision way and replace mysql with mariadb at all is a thing Fesco should have defined while accept the feature from the very begin and the whole discussion how to go would never happened
On 03/09/2013 07:20 PM, Reindl Harald wrote:
and why in the world is this not solved more pragmatically?
my conslusion is
- MariaDB will replace mysql as default
- any package will be linked against mariadb
- Oracle MySQL should only provide the server and not the client-tools
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.
so why is MariaDB not obsoleting mysql without all this versioning tricks and "mysql-oracle" installs the server under "/usr/local/mysql-oracle/" and provides a "mysql-oracle.service"?
This is simply not possible in Fedora: http://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_u...
Honza
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.
Kevin Kofler
On Mon, 11 Mar 2013 19:58:03 +0100, Kevin Kofler kevin.kofler@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.
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
Using alternatives could also be considered. In any case, the packages have to be installable in parallel.
Regards,
Norvald H. Ryeng
(*) 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.
[1] https://fedoraproject.org/wiki/Packaging:Conflicts#Common_Conflicting_Files_...
On 03/12/2013 01:14 PM, Norvald H. Ryeng wrote:
On Mon, 11 Mar 2013 19:58:03 +0100, Kevin Kofler kevin.kofler@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.
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
On Tue, 12 Mar 2013 18:25:02 +0100, Honza Horak hhorak@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@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
On 03/13/2013 09:27 AM, Norvald H. Ryeng wrote:
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.
Yeah, but on the other hand, as soon as there are still packages that doesn't depend on a specific one (use just mysql or mysql-server) -- we need to keep the API the same -- by API I mean name of the systemd unit file, utilities names, ...
Honza
On Wed, 13 Mar 2013 18:03:18 +0100, Honza Horak hhorak@redhat.com wrote:
On 03/13/2013 09:27 AM, Norvald H. Ryeng wrote:
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.
Yeah, but on the other hand, as soon as there are still packages that doesn't depend on a specific one (use just mysql or mysql-server) -- we need to keep the API the same -- by API I mean name of the systemd unit file, utilities names, ...
As I see it, there are two options:
1. Conflicting packages. All dependent packages depend on the virtual provide.
2. Non-conflicting, parallel installable packages. Dependent packages can depend on the virtual provide or directly on one server implementation.
If the servers are conflicting and other packages start depending on specific servers instead of the virtual provide, users will get into unnecessary and unresolvable conflicts.
Regards,
Norvald H. Ryeng
On 03/13/2013 09:27 AM, Norvald H. Ryeng wrote:
On Tue, 12 Mar 2013 18:25:02 +0100, Honza Horak hhorak@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@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.
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).
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"
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.
So, to sum up the above, I've started to believe that we will be able to add "Provides: mysql" also to MySQL packages, while mariadb would be correctly preferred by default.
[1] http://yum.baseurl.org/wiki/CompareProviders
Regards, Honza
On Wed, 13 Mar 2013 18:08:55 +0100, Honza Horak hhorak@redhat.com wrote:
On 03/13/2013 09:27 AM, Norvald H. Ryeng wrote:
On Tue, 12 Mar 2013 18:25:02 +0100, Honza Horak hhorak@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@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.
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
On 14. 3. 2013 at 16:44:58, Norvald H. Ryeng wrote:
On Wed, 13 Mar 2013 18:08:55 +0100, Honza Horak hhorak@redhat.com wrote:
On 03/13/2013 09:27 AM, Norvald H. Ryeng wrote:
On Tue, 12 Mar 2013 18:25:02 +0100, Honza Horak hhorak@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@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.
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.
CCing James and Zdenek, as they are *the guys* when it comes to yum depsolver magic.
Jan
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
On Wed, 2013-03-13 at 18:08 +0100, Honza Horak wrote:
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.
It's documented what the current version of yum does, and it's documented mostly for information purposes ... if you want to install "XYZ" and that is provided by "FOO" and "BAR" then installing either is correct (even if it's not what you want).
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).
Not sure what operation you tested this with, but you probably missed something. When installing a virtual provide, the usual code path would be:
yum install 'mysql(x86-64)' => YumBase.install() => YumBase.bestPacakgesFromList() => YumBase._bestPackageFromList() => Depsolve._compare_providers()
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
Note that we have two major red flags here:
1. We are mixing a _package name_ "mysql" with a provide "mysql", and another package name that is different only by capitalization "MySQL".
2. We have multiple providers of "mysql" and an obsolete of "mysql" (which, again, is based on package name not provides).
...now there are certain parts of yum that will see "FOO" as a package name before it looks for provides, and thus. will never pick the other random packages that also provide "FOO", the relevant ones are that is "yum install" and "yum upgrade" both operate this way.
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.
It's not obvious what you are doing in "yum shell", but rawhide/F19 yum also has the swap command (Eg. yum swap MySQL mariadb). But given the results I wouldn't be shocked if this was the one that represented what a requires would do.
(**) 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"
Yes, basically you are hitting:
cmd line "FOO" => package name "FOO" package name "FOO" => obsoleted by "BAR"
...which doesn't hit compare providers, because there are no providers to compare. But if the old package goes away then this won't be the same, or if the user does "yum install /usr/bin/mysql" (which both the new packages provide and isn't a package name).
Also when a package "XYZ" requires "FOO", then we don't first lookup a package with the name "FOO". Instead we just do a general provides lookup, so that could/would act differently to the above table.
Given that mariadb and MySQL are forks, and will have similar deps. and be on the same arches etc. ... I'd expect compare providers to come down to two things:
1. If all the providers give an "= <version>" for the provide, we'll choose the highest provided version (this is not true in el6 atm. ... if this is going to happen there). Given the above packaging data, 5.6.x > 5.5.x ... thus. MySQL would be preferred.
2. Shortest name (so MySQL will win).
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.
So, to sum up the above, I've started to believe that we will be able to add "Provides: mysql" also to MySQL packages, while mariadb would be correctly preferred by default.
I'd bet against this.
On 03/15/2013 04:22 PM, James Antill wrote:
On Wed, 2013-03-13 at 18:08 +0100, Honza Horak wrote:
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).
Not sure what operation you tested this with, but you probably missed something. When installing a virtual provide, the usual code path would be:
yum install 'mysql(x86-64)' => YumBase.install() => YumBase.bestPacakgesFromList() => YumBase._bestPackageFromList() => Depsolve._compare_providers()
James, thanks for your response. You're right, it does call _compare_providers() when requesting virtual provide.
<snip>
- We are mixing a _package name_ "mysql" with a provide "mysql", and
another package name that is different only by capitalization "MySQL".
Now I see it was not the best idea to call it MySQL, but yum sees that as two different packages, doesn't it?
- We have multiple providers of "mysql" and an obsolete of
"mysql" (which, again, is based on package name not provides).
...now there are certain parts of yum that will see "FOO" as a package name before it looks for provides, and thus. will never pick the other random packages that also provide "FOO", the relevant ones are that is "yum install" and "yum upgrade" both operate this way.
Understood, we'd have to introduce new virtual provides different than the former package name, right? However, I don't think it matters in our case, since mariadb is obsoleting mysql and it should also be the default, so it will behave as we wish in that case (i.e. mariadb is chosen by default) -- or do I miss something?
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.
It's not obvious what you are doing in "yum shell", but rawhide/F19 yum also has the swap command (Eg. yum swap MySQL mariadb).
I ran "remove mariadb" and "install MySQL", which is probably what swap can do.
But given the results I wouldn't be shocked if this was the one that represented what a requires would do.
Sorry, I don't get your point here. Can you explain that a bit, please?
<snip>
Given that mariadb and MySQL are forks, and will have similar deps. and be on the same arches etc. ... I'd expect compare providers to come down to two things:
- If all the providers give an "= <version>" for the provide, we'll
choose the highest provided version (this is not true in el6 atm. ... if this is going to happen there). Given the above packaging data, 5.6.x > 5.5.x ... thus. MySQL would be preferred.
- Shortest name (so MySQL will win).
I see. However, we could do the following adjustments:
1) use epoch in mariadb's "Provides:" (mariadb would win in rule #10 at [1])
2) change the name of the original MySQL package from MySQL to community-mysql -- then it should be safe to assume mariadb will be used before community-mysql. We couldn't use mysql-community because of rule #9 at [1] -- when some package would require mysql, then mysql-community would have better prefix and thus would be chosen before mariadb.
So, if we do these two changes and if rules documented in [1] won't change in the future, we should be able to make yum to choose un-ambiguously mariadb before community-mysql. Or is there still some issue?
Regards, Honza
On Mon, 2013-03-18 at 18:12 +0100, Honza Horak wrote:
On 03/15/2013 04:22 PM, James Antill wrote:
- We are mixing a _package name_ "mysql" with a provide "mysql", and
another package name that is different only by capitalization "MySQL".
Now I see it was not the best idea to call it MySQL, but yum sees that as two different packages, doesn't it?
Kind of ... the rule is that all idempotent operations should match packages without caring about case sensitivity. So "yum install Mysql" doesn't work, but "yum list Mysql" does.
- We have multiple providers of "mysql" and an obsolete of
"mysql" (which, again, is based on package name not provides).
...now there are certain parts of yum that will see "FOO" as a package name before it looks for provides, and thus. will never pick the other random packages that also provide "FOO", the relevant ones are that is "yum install" and "yum upgrade" both operate this way.
Understood, we'd have to introduce new virtual provides different than the former package name, right?
Yeh.
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.
It's not obvious what you are doing in "yum shell", but rawhide/F19 yum also has the swap command (Eg. yum swap MySQL mariadb).
I ran "remove mariadb" and "install MySQL", which is probably what swap can do.
Right, I see what you mean ... I figured the "swap"/shell was at the same level as the install/upgrade.
But given the results I wouldn't be shocked if this was the one that represented what a requires would do.
Sorry, I don't get your point here. Can you explain that a bit, please?
What I meant is that given your testcase wasn't hitting compare_providers, and that from what I could see I'd expect compare_providers to choose MySQL over mariadb the shell case might be doing a real compare_providers test (and thus. would be what happens if you upgraded XYZ that depended on a "newer mysql").
Given that mariadb and MySQL are forks, and will have similar deps. and be on the same arches etc. ... I'd expect compare providers to come down to two things:
- If all the providers give an "= <version>" for the provide, we'll
choose the highest provided version (this is not true in el6 atm. ... if this is going to happen there). Given the above packaging data, 5.6.x > 5.5.x ... thus. MySQL would be preferred.
- Shortest name (so MySQL will win).
I see. However, we could do the following adjustments:
- use epoch in mariadb's "Provides:" (mariadb would win in rule #10 at
[1])
- change the name of the original MySQL package from MySQL to
community-mysql -- then it should be safe to assume mariadb will be used before community-mysql. We couldn't use mysql-community because of rule #9 at [1] -- when some package would require mysql, then mysql-community would have better prefix and thus would be chosen before mariadb.
Yeh, with either/both of those changes I'd expect yum to choose mariadb over the other package ... all other things being equal.
On 03/18/2013 03:17 PM, James Antill wrote:
Kind of ... the rule is that all idempotent operations should match packages without caring about case sensitivity. So "yum install Mysql" doesn't work, but "yum list Mysql" does.
<pedantic> "Idempotent" means that that multiple applications of an operation have no further effect after the first one---so "yum install" is actually idempotent. </pedantic>
So, what is the rule you are referring to? perhaps it could be described as covering "inconsequential operations".
On Tue, 2013-03-19 at 10:37 -0400, Przemek Klosowski wrote:
On 03/18/2013 03:17 PM, James Antill wrote:
Kind of ... the rule is that all idempotent operations should match packages without caring about case sensitivity. So "yum install Mysql" doesn't work, but "yum list Mysql" does.
<pedantic> "Idempotent" means that that multiple applications of an operation have no further effect after the first one
True.
---so "yum install" is actually idempotent. </pedantic>
No, as install can still do upgrades etc.
So, what is the rule you are referring to? perhaps it could be described as covering "inconsequential operations".
Yeh, that's probably close. A longer explanation is probably:
Operations that are "read-only", from the users point of view, will match packages ignoring case sensitivity.
...or as a quick hack, if it says "list/info/search" at the end then it's probably good :).
Le Lun 18 mars 2013 18:12, Honza Horak a écrit :
Now I see it was not the best idea to call it MySQL, but yum sees that as two different packages, doesn't it?
Honestly? Capitalized package names are a PITA that break searches and make users miserable. The only reason they're not banned in Fedora (as they are in other distros) is the huge legacy of capitalized perl packages. And even perl packagers are not vicious enough to use a capital as first letter of their names. (people managed to get rid of perl use in livecds but RHL's perl tooling roots still haunt us).
Don't use caps in package names. Whatever reason you have, it's wrong. If you think camelcase package names are cool, you're doubly wrong. Like /opt caps use is the mark of horrid proprietary packages where marketing overrode common sense.
I'd like to discuss the topic about virtual provides in a general context (not related to MySQL->MariaDB replacement) to find out what actually is a consensus in Fedora about an issue when "two packages provide the same (not only) virtual symbol" -- particularly what package maintainers could/should depend on.
On 03/15/2013 04:22 PM, James Antill wrote:
On Wed, 2013-03-13 at 18:08 +0100, Honza Horak wrote:
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.
It's documented what the current version of yum does, and it's documented mostly for information purposes ... if you want to install "XYZ" and that is provided by "FOO" and "BAR" then installing either is correct (even if it's not what you want).
That's probably how it should work eventually, but I believe we should also be *sure* what will be installed in case nobody requires either FOO nor BAR explicitly -- something like distribution-wide default.
Currently, we can follow the steps how scores of providers are count [1]. However, since you wrote "it's documented mostly for information purposes", the question is -- can we depend on it?
Let me elaborate that a bit more. If we can depend on it, it means it is defined somehow -- so it would make sense also to re-define that behavior by user if there's a reason for that (i.e. let users to choose one of the provider).
The idea I've in my mind is to achieve this by a yum plugin (which would use compare_providers hook), which would basically adjust scores for possible providers according to a config file.
In case of MySQL/mariadb (just for demonstration) the config file would contain say: MySQL +10000 mariadb -10000 which would tell yum to prioritize MySQL.
I'm sure that there are several other use cases for such utility. It would bring a bit more complexity on the one hand, but would decrease ambiguity in specific cases on the other hand.
Any ideas about such tool/plugin?
Cheers, Honza
On Mon, Mar 18, 2013 at 6:30 PM, Honza Horak hhorak@redhat.com wrote:
In case of MySQL/mariadb (just for demonstration) the config file would contain say: MySQL +10000 mariadb -10000 which would tell yum to prioritize MySQL.
I'm sure that there are several other use cases for such utility. It would bring a bit more complexity on the one hand, but would decrease ambiguity in specific cases on the other hand.
Any ideas about such tool/plugin?
I'm not following the MySQL/mariadb packaging discussion in full detail - however, if we got to the point of discussing special yum plugins, wouldn't it be much simpler to
* Modify the 10 packages that require mysql-server, the 19 packages that require mysql, the 3 packages that require mysql-libs (all F18 counts) to require mariadb-* explicitly instead of using the virtual provide
* Make sure that only mariadb-libs, not Oracle MySQL, Provides: the libmysqlclient soname?
That's about 35 packages to touch, and all but one of them trivial modifications.
(On the general question: multiple providers are always problematic - the interfaces are usually mostly but not fully compatible, some of the cases won't be tested, etc., so I'm not too enthusiastic about encouraging them.) Mirek
Miloslav Trmač (mitr@volny.cz) said:
On Mon, Mar 18, 2013 at 6:30 PM, Honza Horak hhorak@redhat.com wrote:
In case of MySQL/mariadb (just for demonstration) the config file would contain say: MySQL +10000 mariadb -10000 which would tell yum to prioritize MySQL.
I'm sure that there are several other use cases for such utility. It would bring a bit more complexity on the one hand, but would decrease ambiguity in specific cases on the other hand.
Any ideas about such tool/plugin?
I'm not following the MySQL/mariadb packaging discussion in full detail - however, if we got to the point of discussing special yum plugins, wouldn't it be much simpler to
- Modify the 10 packages that require mysql-server, the 19 packages
that require mysql, the 3 packages that require mysql-libs (all F18 counts) to require mariadb-* explicitly instead of using the virtual provide
- Make sure that only mariadb-libs, not Oracle MySQL, Provides: the
libmysqlclient soname?
That's about 35 packages to touch, and all but one of them trivial modifications.
This does sound much simpler, IMO.
Bill
On 03/18/2013 07:17 PM, Bill Nottingham wrote:
I'm not following the MySQL/mariadb packaging discussion in full
detail - however, if we got to the point of discussing special yum plugins, wouldn't it be much simpler to
- Modify the 10 packages that require mysql-server, the 19 packages
that require mysql, the 3 packages that require mysql-libs (all F18 counts) to require mariadb-* explicitly instead of using the virtual provide
- Make sure that only mariadb-libs, not Oracle MySQL, Provides: the
libmysqlclient soname?
That's about 35 packages to touch, and all but one of them trivial modifications.
This does sound much simpler, IMO.
It does, but it would be hard to install MySQL in case any package requries mariadb, since the two packages conflict. And making the packages non-conflicting doesn't seem so simple -- it would mean to change location of the binaries or change their file-names, which would mean quite a lot of patching. But generally, if we find a way how to make the packages to be usable and non-conflicting, it could work fine.
Honza
On Tue, 19 Mar 2013 08:56:04 +0100, Honza Horak hhorak@redhat.com wrote:
On 03/18/2013 07:17 PM, Bill Nottingham wrote:
I'm not following the MySQL/mariadb packaging discussion in full
detail - however, if we got to the point of discussing special yum plugins, wouldn't it be much simpler to
- Modify the 10 packages that require mysql-server, the 19 packages
that require mysql, the 3 packages that require mysql-libs (all F18 counts) to require mariadb-* explicitly instead of using the virtual provide
- Make sure that only mariadb-libs, not Oracle MySQL, Provides: the
libmysqlclient soname?
I would like non-conflicting libraries as well.
That's about 35 packages to touch, and all but one of them trivial modifications.
This does sound much simpler, IMO.
It does, but it would be hard to install MySQL in case any package requries mariadb, since the two packages conflict. And making the packages non-conflicting doesn't seem so simple -- it would mean to change location of the binaries or change their file-names, which would mean quite a lot of patching. But generally, if we find a way how to make the packages to be usable and non-conflicting, it could work fine.
I would also like to have non-conflicting packages. I don't think changing the names of the binaries would be that much work, but there are config files, scripts that refer to the binaries, etc. It's some work, but I think it's doable. And it would solve much of our headache. At least, I think it's worth considering.
Regards,
Norvald H. Ryeng
On Mon, 2013-03-18 at 18:42 +0100, Miloslav Trmač wrote:
On Mon, Mar 18, 2013 at 6:30 PM, Honza Horak hhorak@redhat.com wrote:
In case of MySQL/mariadb (just for demonstration) the config file would contain say: MySQL +10000 mariadb -10000 which would tell yum to prioritize MySQL.
I'm sure that there are several other use cases for such utility. It would bring a bit more complexity on the one hand, but would decrease ambiguity in specific cases on the other hand.
Any ideas about such tool/plugin?
I'm not following the MySQL/mariadb packaging discussion in full detail - however, if we got to the point of discussing special yum plugins, wouldn't it be much simpler to
We, didn't, really.
- Modify the 10 packages that require mysql-server, the 19 packages
that require mysql, the 3 packages that require mysql-libs (all F18 counts) to require mariadb-* explicitly instead of using the virtual provide
This means users can't choose between the mysql's if they want to, so if we do this it'd be much easier to just say "we'll only have a single `mysql' in Fedora" and then we'd just have to add one more obsolete to mariadb and everything works perfectly.
Am 18.03.2013 20:55, schrieb James Antill:
This means users can't choose between the mysql's if they want to, so if we do this it'd be much easier to just say "we'll only have a single `mysql' in Fedora" and then we'd just have to add one more obsolete to mariadb and everything works perfectly.
and why is this not happening instead a lot of workarounds and hacks in SPEC files and mangle sonames which makes anything related to mysql ar whatever fork-name ugly at all?
by introduce systemd nobody cared about "having another working initd" without punish users in the way to early F15 state but now in the case of user-applications it happens in a dirty way?
Reindl Harald wrote:
Am 18.03.2013 20:55, schrieb James Antill:
This means users can't choose between the mysql's if they want to, so if we do this it'd be much easier to just say "we'll only have a single `mysql' in Fedora" and then we'd just have to add one more obsolete to mariadb and everything works perfectly.
and why is this not happening instead a lot of workarounds and hacks in SPEC files and mangle sonames which makes anything related to mysql ar whatever fork-name ugly at all?
+1
In light of the issues that have come up, can the decision of continuing to ship MySQL in Fedora PLEASE be revisited? Just having MariaDB Obsolete it for good really makes everyone's life easier. There is just no practical way to ship both.
Kevin Kofler
On Mon, 2013-03-18 at 18:30 +0100, Honza Horak wrote:
I'd like to discuss the topic about virtual provides in a general context (not related to MySQL->MariaDB replacement) to find out what actually is a consensus in Fedora about an issue when "two packages provide the same (not only) virtual symbol" -- particularly what package maintainers could/should depend on.
On 03/15/2013 04:22 PM, James Antill wrote:
On Wed, 2013-03-13 at 18:08 +0100, Honza Horak wrote:
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.
It's documented what the current version of yum does, and it's documented mostly for information purposes ... if you want to install "XYZ" and that is provided by "FOO" and "BAR" then installing either is correct (even if it's not what you want).
That's probably how it should work eventually, but I believe we should also be *sure* what will be installed in case nobody requires either FOO nor BAR explicitly -- something like distribution-wide default.
Doing it as a plugin would be a pretty big fail IMO, doing it in core is fairly simple and we did a PoC a _long_ time ago:
http://james.fedorapeople.org/yum/patches/yum-best-providers-metadata.patch
...the main problem was what to do if we committed the patch, how does the data get into the repo. who owns it ... then how do we make it so that spins could have different data (Eg. kdm vs. gdm). It's much like the "app. data" problem, except there was never the huge extra problem of it being a package too ... so if app. data ever gets in, that might show a way for someone to push this data in too (guess you'd want to talk to dnf maintainer though :).
My main point was that the above is informational, and while you can use it to game which packages are installed "by default" there are no guarantees that it will remain compatible until the end of time.
Norvald H. Ryeng wrote:
This dependency is a problem. It makes it impossible to install MySQL-server on a KDE system since mariadb-server and MySQL-server conflict.
That just shows how broken it is to have both in Fedora at the same time.
We need to make sure that 1. the live CD composes don't fail due to conflicts and 2. our users get the default database flavor, not a random one, and I don't see any other way to enforce this than to require mariadb-server directly.
Kevin Kofler
On Tue, 12 Mar 2013 23:31:46 +0100, Kevin Kofler kevin.kofler@chello.at wrote:
Norvald H. Ryeng wrote:
This dependency is a problem. It makes it impossible to install MySQL-server on a KDE system since mariadb-server and MySQL-server conflict.
That just shows how broken it is to have both in Fedora at the same time.
The current solution is broken, but I hope we can find a way to have both.
We need to make sure that
- the live CD composes don't fail due to conflicts and
- our users get the default database flavor, not a random one,
and I don't see any other way to enforce this than to require mariadb-server directly.
Are you saying that you would always like to have one particular server implementation, or could you depend on a common provide and let the user choose one or the other (as long as the default situation is solved)? This will influence the possibilities we have wrt. server packaging:
- If your answer is that you would like akonadi-mysql to always choose MariaDB or MySQL (no user choice), we have to make MariaDB and MySQL parallel installable.
- If you are happy with either implementation (default, or changed manually by the user), we can have conflicting MariaDB and MySQL packages.
Regards,
Norvald H. Ryeng
Am 11.03.2013 19:12, schrieb Honza Horak:
On 03/09/2013 07:20 PM, Reindl Harald wrote:
and why in the world is this not solved more pragmatically?
my conslusion is
- MariaDB will replace mysql as default
- any package will be linked against mariadb
- Oracle MySQL should only provide the server and not the client-tools
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.
so you can not have both in Fedora
so why is MariaDB not obsoleting mysql without all this versioning tricks and "mysql-oracle" installs the server under "/usr/local/mysql-oracle/" and provides a "mysql-oracle.service"?
This is simply not possible in Fedora: http://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_u...
so you can not have both in Fedora
do the switch to mariadb or leave things as they where instead create problems afters problems or leave mysql untouched at all
On Mon, Mar 11, 2013 at 2:12 PM, Honza Horak hhorak@redhat.com wrote:
so why is MariaDB not obsoleting mysql without all this versioning tricks and "mysql-oracle" installs the server under "/usr/local/mysql-oracle/" and provides a "mysql-oracle.service"?
This is simply not possible in Fedora: http://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_u...
Should an exception be allowed - or is the rule so rigid ?
On 03/14/2013 05:03 AM, Subhendu Ghosh wrote:
On Mon, Mar 11, 2013 at 2:12 PM, Honza Horak hhorak@redhat.com wrote:
so why is MariaDB not obsoleting mysql without all this versioning tricks and "mysql-oracle" installs the server under "/usr/local/mysql-oracle/" and provides a "mysql-oracle.service"?
This is simply not possible in Fedora: http://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_u...
Should an exception be allowed - or is the rule so rigid ?
Anything under /usr/local (except of the basic directory layout) is supposed to be 100% under a user's control and not to be touched by distributions.
Somewhat oversimplified, this means /usr/local is off-limits of Fedora, no exceptions allowed.
Ralf
On 13/03/13 09:25 PM, Ralf Corsepius wrote:
On 03/14/2013 05:03 AM, Subhendu Ghosh wrote:
On Mon, Mar 11, 2013 at 2:12 PM, Honza Horak hhorak@redhat.com wrote:
so why is MariaDB not obsoleting mysql without all this versioning tricks and "mysql-oracle" installs the server under "/usr/local/mysql-oracle/" and provides a "mysql-oracle.service"?
This is simply not possible in Fedora: http://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_u...
Should an exception be allowed - or is the rule so rigid ?
Anything under /usr/local (except of the basic directory layout) is supposed to be 100% under a user's control and not to be touched by distributions.
Somewhat oversimplified, this means /usr/local is off-limits of Fedora, no exceptions allowed.
...and for the love of all that's good and holy, please no-one suggest /opt.