Re: Yum plugin for prioritize providers [was Re: Fwd: MariaDB replacing MySQL]
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yum plugin for prioritize providers [was Re: Fwd: MariaDB replacing MySQL]
On Tue, 19 Mar 2013 08:56:04 +0100, Honza Horak 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
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. > > "Idempotent" means that that multiple applications of an > operation have no further effect after the first one True. > ---so "yum install" > is actually idempotent. 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 :). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
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. "Idempotent" means that that multiple applications of an operation have no further effect after the first one---so "yum install" is actually idempotent. So, what is the rule you are referring to? perhaps it could be described as covering "inconsequential operations". -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yum plugin for prioritize providers [was Re: Fwd: MariaDB replacing MySQL]
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yum plugin for prioritize providers [was Re: Fwd: MariaDB replacing MySQL]
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? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
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. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yum plugin for prioritize providers [was Re: Fwd: MariaDB replacing MySQL]
On Mon, 2013-03-18 at 18:42 +0100, Miloslav Trmač wrote: > On Mon, Mar 18, 2013 at 6:30 PM, Honza Horak wrote: > > In case of MySQL/mariadb (just for demonstration) the config file would > > contain say: > > MySQL +1 > > mariadb -1 > > 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yum plugin for prioritize providers [was Re: Fwd: MariaDB replacing MySQL]
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On Mon, 2013-03-18 at 18:12 +0100, Honza Horak wrote: > On 03/15/2013 04:22 PM, James Antill wrote: > > 1. 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. > > 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. > > 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: > > > > 1. If all the providers give an "= " 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). > > 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. Yeh, with either/both of those changes I'd expect yum to choose mariadb over the other package ... all other things being equal. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yum plugin for prioritize providers [was Re: Fwd: MariaDB replacing MySQL]
Miloslav Trmač (m...@volny.cz) said: > On Mon, Mar 18, 2013 at 6:30 PM, Honza Horak wrote: > > In case of MySQL/mariadb (just for demonstration) the config file would > > contain say: > > MySQL +1 > > mariadb -1 > > 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yum plugin for prioritize providers [was Re: Fwd: MariaDB replacing MySQL]
On Mon, Mar 18, 2013 at 6:30 PM, Honza Horak wrote: > In case of MySQL/mariadb (just for demonstration) the config file would > contain say: > MySQL +1 > mariadb -1 > 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Yum plugin for prioritize providers [was Re: Fwd: MariaDB replacing MySQL]
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 +1 mariadb -1 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 [1] http://yum.baseurl.org/wiki/CompareProviders -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
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. 1. 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? 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. 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? 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 "= " 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). 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 [1] http://yum.baseurl.org/wiki/CompareProviders -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL
Jared K. Smith wrote: > Yes, we heard you the first three times you said that -- and it's > still not happening, at least for now. Each of the three times pointed out a new showstopper-level problem with having the 2 forks coexist. It's sad that no amount of technical impossibility is convincing the decision-makers to rethink their dead-end decision. > You're not doing yourself any favors by repeating yourself, especially > when others on the thread are working through the technical details of how > to make things work properly. No amount of "technical details" is going to make things work PROPERLY. It is provably impossible. At best we are going to have a very ugly and user- unfriendly hackaround. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
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 "= " 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. > [1] http://yum.baseurl.org/wiki/CompareProviders -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On 14. 3. 2013 at 16:44:58, Norvald H. Ryeng wrote: > On Wed, 13 Mar 2013 18:08:55 +0100, Honza Horak wrote: > > On 03/13/2013 09:27 AM, Norvald H. Ryeng wrote: > >> On Tue, 12 Mar 2013 18:25:02 +0100, Honza Horak > >> > >> wrote: > >>> On 03/12/2013 01:14 PM, Norvald H. Ryeng wrote: > On Mon, 11 Mar 2013 19:58:03 +0100, Kevin Kofler > > 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On Wed, 13 Mar 2013 18:03:18 +0100, Honza Horak 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On Wed, 13 Mar 2013 18:08:55 +0100, Honza Horak wrote: On 03/13/2013 09:27 AM, Norvald H. Ryeng wrote: On Tue, 12 Mar 2013 18:25:02 +0100, Honza Horak wrote: On 03/12/2013 01:14 PM, Norvald H. Ryeng wrote: On Mon, 11 Mar 2013 19:58:03 +0100, Kevin Kofler 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
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 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_under_.2Fsrv.2C_.2Fopt.2C_or_.2Fusr.2Flocal 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On 03/14/2013 05:03 AM, Subhendu Ghosh wrote: On Mon, Mar 11, 2013 at 2:12 PM, Honza Horak 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_under_.2Fsrv.2C_.2Fopt.2C_or_.2Fusr.2Flocal 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On Mon, Mar 11, 2013 at 2:12 PM, Honza Horak 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_under_.2Fsrv.2C_.2Fopt.2C_or_.2Fusr.2Flocal Should an exception be allowed - or is the rule so rigid ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL
On Wed, Mar 13, 2013 at 5:27 PM, Kevin Kofler wrote: > The best would be to just remove MySQL from the distribution. Sorry. Yes, we heard you the first three times you said that -- and it's still not happening, at least for now. You're not doing yourself any favors by repeating yourself, especially when others on the thread are working through the technical details of how to make things work properly. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL
Norvald H. Ryeng wrote: > The best would be to make the packages non-conflicting, either completely > separate or using alternatives to set a default. The best would be to just remove MySQL from the distribution. Sorry. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On 03/13/2013 09:27 AM, Norvald H. Ryeng wrote: On Tue, 12 Mar 2013 18:25:02 +0100, Honza Horak wrote: On 03/12/2013 01:14 PM, Norvald H. Ryeng wrote: On Mon, 11 Mar 2013 19:58:03 +0100, Kevin Kofler 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On Tue, 12 Mar 2013 23:31:46 +0100, Kevin Kofler 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 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. 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On Tue, 12 Mar 2013 18:25:02 +0100, Honza Horak wrote: On 03/12/2013 01:14 PM, Norvald H. Ryeng wrote: On Mon, 11 Mar 2013 19:58:03 +0100, Kevin Kofler 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL
On Tue, 12 Mar 2013 17:59:50 +0100, Honza Horak wrote: On 03/06/2013 02:44 PM, Miloslav Trmač wrote: On Wed, Mar 6, 2013 at 2:35 PM, Norvald H. Ryeng wrote: In practice, this means that it will be almost impossible to install MySQL in Fedora. The recipe in the feature page [1] requires the user to 1. edit yum.conf to set excludes=mariadb* and obsoletes=0, 2. run yum shell to replace the packages, and 3. edit yum.conf again to remove obsoletes=0. I think that the above recipe wasn't updated for the package rename; with the new name, a simple "yum install MySQL" should work. Honza, is that how it was designed? Yes, the feature page has been updated to correspond with the renaming of mysql package. Shortly, users will be able to install MySQL-server in a usual way (yum remove mariadb-server ; yum install MySQL-server). What is a bit different -- MySQL-server requires "mysql" virtual symbol to have utilities like mysql, mysqldump, etc. These are by default provided by package mariadb, so it means MySQL-server will require mariadb base package (in the same manner as all other packages in Fedora, which need mysql client utilities). I believe the tools should match the server. I.e, MariaDB tools for MariaDB server, MySQL tools for MySQL server. I believe there are already minor protocol differences between MariaDB and MySQL. Having a MySQL server without fully working admin tools is not good. The FESCo decision from the minutes was: feature owners are asked to make it possible to install the MySQL stand-alone server (only) so dependencies on the client libraries are not a concern; Fedora packages are expected to use the MariaDB client libraries. Everything that depends on mysql will then require mariadb to be installed, but having both mariadb and MySQL at the same time is not going to work unless the files in the mariadb packages are renamed. 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. I believe conflicting server packages are not an issue -- users will be able to use one or another. I disagree. The best example of this not working is the akonadi-mysql package which now depends directly on mariadb-server. This makes it impossible/very much harder to install MySQL on a KDE desktop. Also, there are applications depending on mysql or mysql-server. If the MySQL packages aren't allowed to provide those virtual provides, it will be impossible to use those applications with MySQL. The best would be to make the packages non-conflicting, either completely separate or using alternatives to set a default. Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On 03/12/2013 01:14 PM, Norvald H. Ryeng wrote: On Mon, 11 Mar 2013 19:58:03 +0100, Kevin Kofler 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL
On 03/06/2013 02:44 PM, Miloslav Trmač wrote: On Wed, Mar 6, 2013 at 2:35 PM, Norvald H. Ryeng wrote: In practice, this means that it will be almost impossible to install MySQL in Fedora. The recipe in the feature page [1] requires the user to 1. edit yum.conf to set excludes=mariadb* and obsoletes=0, 2. run yum shell to replace the packages, and 3. edit yum.conf again to remove obsoletes=0. I think that the above recipe wasn't updated for the package rename; with the new name, a simple "yum install MySQL" should work. Honza, is that how it was designed? Yes, the feature page has been updated to correspond with the renaming of mysql package. Shortly, users will be able to install MySQL-server in a usual way (yum remove mariadb-server ; yum install MySQL-server). What is a bit different -- MySQL-server requires "mysql" virtual symbol to have utilities like mysql, mysqldump, etc. These are by default provided by package mariadb, so it means MySQL-server will require mariadb base package (in the same manner as all other packages in Fedora, which need mysql client utilities). The FESCo decision from the minutes was: feature owners are asked to make it possible to install the MySQL stand-alone server (only) so dependencies on the client libraries are not a concern; Fedora packages are expected to use the MariaDB client libraries. Everything that depends on mysql will then require mariadb to be installed, but having both mariadb and MySQL at the same time is not going to work unless the files in the mariadb packages are renamed. 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. I believe conflicting server packages are not an issue -- users will be able to use one or another. Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL
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_under_.2Fsrv.2C_.2Fopt.2C_or_.2Fusr.2Flocal 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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On Mon, 11 Mar 2013 19:58:03 +0100, Kevin Kofler 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_Cases_and_Solutions -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
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_under_.2Fsrv.2C_.2Fopt.2C_or_.2Fusr.2Flocal Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL
Miloslav Trmač wrote: > The FESCo decision from the minutes was: >> feature owners are asked to make it possible to install the MySQL >> stand-alone server (only) > so dependencies on the client libraries are not a concern; Fedora > packages are expected to use the MariaDB client libraries. In other words, the conflicting MySQL-libs package which is breaking live image composes and RPM Fusion builds (see the threads on this list and the rpmfusion-devel list) needs to go away NOW! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL
On Sat, 09 Mar 2013 19:20:08 +0100 Reindl Harald 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 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: MariaDB replacing MySQL
> "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 Organisation: the lounge interactive design An: Development discussions related to Fedora 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 > > https://fedorahosted.org/fesco/ 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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL
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 https://fedorahosted.org/fesco/ Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL
On Wed, Mar 6, 2013 at 2:35 PM, Norvald H. Ryeng wrote: > In practice, this means that it will be almost impossible to install MySQL > in Fedora. The recipe in the feature page [1] requires the user to > > 1. edit yum.conf to set excludes=mariadb* and obsoletes=0, > 2. run yum shell to replace the packages, and > 3. edit yum.conf again to remove obsoletes=0. I think that the above recipe wasn't updated for the package rename; with the new name, a simple "yum install MySQL" should work. Honza, is that how it was designed? > If the MySQL packages don't provide mysql*, how can they fulfill > dependencies? The FESCo decision from the minutes was: > feature owners are asked to make it possible to install the MySQL stand-alone > server (only) so dependencies on the client libraries are not a concern; Fedora packages are expected to use the MariaDB client libraries. > Everything that depends on mysql will then require mariadb to > be installed, but having both mariadb and MySQL at the same time is not > going to work unless the files in the mariadb packages are renamed. 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. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL
On Tue, 05 Mar 2013 19:14:25 +0100, Honza Horak wrote: On 03/05/2013 11:07 AM, Norvald H. Ryeng wrote: On Thu, 14 Feb 2013 16:17:00 +0100, Tom Lane wrote: The way this worked in the past (and still does on RHEL and some other distros) is that MySQL AB provided RPMs named "MySQL", "MySQL-server", etc, which simply conflicted with the Red Hat-supplied packages named "mysql", "mysql-server", etc. Perhaps it would be best to continue that naming tradition, ie establish a new Oracle-maintained Fedora package named "MySQL", instead of figuring out how to transition maintainership of the "mysql" packages. This would give us some more wiggle room about managing the transition --- in particular, it's hard to see how we manage Obsoletes/Provides linkages in any sane fashion if the "mysql" package name continues in use. I think we're going to have to end up with a design in which "mysql" becomes essentially a virtual Provides name. We now have a set of working 5.6.10 packages. The packages pass mtr tests and we've tested some of the packages that depend on MySQL (php, perl-DBD-MySQL, etc.). It all seems to be working well, so I think we're ready to get it into rawhide. I believe Bjørn Munch has already contacted you about how to upload, etc. I'm glad to hear that things get move on with MySQL-5.6 effort. We've kept the existing package names. I don't understand the reasons behind the name change you suggest. Honza Horák has added a real-mysql virtual provides, and this is provided by the existing mysql and mariadb packages, so it seems the infrastructure you suggest is already in place. Our 5.6.10 packages are just an upgrade of the existing mysql packages, so I see no need for a name change, and a change now would break upgrades for users that already have the mysql packages installed. We're still going to make mariadb the default in F19 as proposed in the Feature page. Since depended packages are now built against libmysqlclient.so from mariadb, we should really ensure mariadb package will be installed (if not explicitly requested otherwise by users), because MySQL lacks some client side features that mariadb adds -- so keeping MySQL installed would introduce potential compatibility problems. About the issues with the current way how the things are handling -- we introduced real-mysql virtual provides to distinguish between mysql package and mysql virtual name -- that doesn't work well in all aspects, it is not very clean and it also brings ambiguities. We decided to solve that as proposed above -- to introduce a new package MySQL (dist-git already done) where original MySQL project will be kept and eventually upgraded to 5.6 by contributors from Oracle. Package mysql will be retired as of F19 and the name "mysql" will exist only as a virtual provide for compatibility reasons. mariadb will provide "mysql" names, while MySQL won't -- ideally both packages could provide it but RPM cannot define a priority for preferring one of two packages that provide the same symbol. Is that right, Jan or Ales? Or anything changed in that field? In practice, this means that it will be almost impossible to install MySQL in Fedora. The recipe in the feature page [1] requires the user to 1. edit yum.conf to set excludes=mariadb* and obsoletes=0, 2. run yum shell to replace the packages, and 3. edit yum.conf again to remove obsoletes=0. This is not very user friendly. One thing is that the user would have to jump through all these hoops just to install a single package, but they also have to find this recipe in the first place. I fear this is the same as telling users no, you can't get MySQL. If the MySQL packages don't provide mysql*, how can they fulfill dependencies? Everything that depends on mysql will then require mariadb to be installed, but having both mariadb and MySQL at the same time is not going to work unless the files in the mariadb packages are renamed. I also think that this is not what FESCo decided. As I understand the FESCo meeting minutes [2], the versioned obsolete is there to make it possible for existing users to continue using MySQL if the package is still actively maintained. The approach you describe will move all users away from MySQL on upgrade, and they have to follow the recipe above to get back to the packages they had before. That will cause a lot of confusion. Regards, Norvald H. Ryeng [1] https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB [2] http://meetbot.fedoraproject.org/teams/fesco/fesco.2013-01-30-18.01.log.html#l-313 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL [was Re: Should MariaDB touch my.cnf in %post?]
On 5. 3. 2013 at 19:14:25, Honza Horak wrote: > On 03/05/2013 11:07 AM, Norvald H. Ryeng wrote: > > On Thu, 14 Feb 2013 16:17:00 +0100, Tom Lane wrote: > >> The way this worked in the past (and still does on RHEL and some other > >> distros) is that MySQL AB provided RPMs named "MySQL", "MySQL-server", > >> etc, which simply conflicted with the Red Hat-supplied packages named > >> "mysql", "mysql-server", etc. Perhaps it would be best to continue that > >> naming tradition, ie establish a new Oracle-maintained Fedora package > >> named "MySQL", instead of figuring out how to transition maintainership > >> of the "mysql" packages. This would give us some more wiggle room about > >> managing the transition --- in particular, it's hard to see how we > >> manage Obsoletes/Provides linkages in any sane fashion if the "mysql" > >> package name continues in use. I think we're going to have to end up > >> with a design in which "mysql" becomes essentially a virtual Provides > >> name. > > > > We now have a set of working 5.6.10 packages. The packages pass mtr > > tests and we've tested some of the packages that depend on MySQL (php, > > perl-DBD-MySQL, etc.). It all seems to be working well, so I think we're > > ready to get it into rawhide. I believe Bjørn Munch has already > > contacted you about how to upload, etc. > > I'm glad to hear that things get move on with MySQL-5.6 effort. > > > We've kept the existing package names. I don't understand the reasons > > behind the name change you suggest. Honza Horák has added a real-mysql > > virtual provides, and this is provided by the existing mysql and mariadb > > packages, so it seems the infrastructure you suggest is already in > > place. Our 5.6.10 packages are just an upgrade of the existing mysql > > packages, so I see no need for a name change, and a change now would > > break upgrades for users that already have the mysql packages installed. > > We're still going to make mariadb the default in F19 as proposed in the > Feature page. Since depended packages are now built against > libmysqlclient.so from mariadb, we should really ensure mariadb package > will be installed (if not explicitly requested otherwise by users), > because MySQL lacks some client side features that mariadb adds -- so > keeping MySQL installed would introduce potential compatibility problems. > > About the issues with the current way how the things are handling -- we > introduced real-mysql virtual provides to distinguish between mysql > package and mysql virtual name -- that doesn't work well in all aspects, > it is not very clean and it also brings ambiguities. > > We decided to solve that as proposed above -- to introduce a new package > MySQL (dist-git already done) where original MySQL project will be kept > and eventually upgraded to 5.6 by contributors from Oracle. > > Package mysql will be retired as of F19 and the name "mysql" will exist > only as a virtual provide for compatibility reasons. mariadb will > provide "mysql" names, while MySQL won't -- ideally both packages could > provide it but RPM cannot define a priority for preferring one of two > packages that provide the same symbol. Is that right, Jan or Ales? Or > anything changed in that field? Nothing has changed in this area - there are some heuristics used, I think the most used one is to pick the package with the shortest name ;-) I'm now pushing for proper support of versioning in provides, that might help you. But even if we decide to support it, we are still looking on a time frame of at least a month or so. > So, the current plan with a new MySQL package will result in much more > cleaner solution and should avoid ambiguities. > > Regards, > Honza > > Note: In case there are some reactions, I'd like to excuse myself that > I'll be off-line for a few days now and won't be able to respond until > Monday. signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
MariaDB replacing MySQL [was Re: Should MariaDB touch my.cnf in %post?]
On 03/05/2013 11:07 AM, Norvald H. Ryeng wrote: On Thu, 14 Feb 2013 16:17:00 +0100, Tom Lane wrote: The way this worked in the past (and still does on RHEL and some other distros) is that MySQL AB provided RPMs named "MySQL", "MySQL-server", etc, which simply conflicted with the Red Hat-supplied packages named "mysql", "mysql-server", etc. Perhaps it would be best to continue that naming tradition, ie establish a new Oracle-maintained Fedora package named "MySQL", instead of figuring out how to transition maintainership of the "mysql" packages. This would give us some more wiggle room about managing the transition --- in particular, it's hard to see how we manage Obsoletes/Provides linkages in any sane fashion if the "mysql" package name continues in use. I think we're going to have to end up with a design in which "mysql" becomes essentially a virtual Provides name. We now have a set of working 5.6.10 packages. The packages pass mtr tests and we've tested some of the packages that depend on MySQL (php, perl-DBD-MySQL, etc.). It all seems to be working well, so I think we're ready to get it into rawhide. I believe Bjørn Munch has already contacted you about how to upload, etc. I'm glad to hear that things get move on with MySQL-5.6 effort. We've kept the existing package names. I don't understand the reasons behind the name change you suggest. Honza Horák has added a real-mysql virtual provides, and this is provided by the existing mysql and mariadb packages, so it seems the infrastructure you suggest is already in place. Our 5.6.10 packages are just an upgrade of the existing mysql packages, so I see no need for a name change, and a change now would break upgrades for users that already have the mysql packages installed. We're still going to make mariadb the default in F19 as proposed in the Feature page. Since depended packages are now built against libmysqlclient.so from mariadb, we should really ensure mariadb package will be installed (if not explicitly requested otherwise by users), because MySQL lacks some client side features that mariadb adds -- so keeping MySQL installed would introduce potential compatibility problems. About the issues with the current way how the things are handling -- we introduced real-mysql virtual provides to distinguish between mysql package and mysql virtual name -- that doesn't work well in all aspects, it is not very clean and it also brings ambiguities. We decided to solve that as proposed above -- to introduce a new package MySQL (dist-git already done) where original MySQL project will be kept and eventually upgraded to 5.6 by contributors from Oracle. Package mysql will be retired as of F19 and the name "mysql" will exist only as a virtual provide for compatibility reasons. mariadb will provide "mysql" names, while MySQL won't -- ideally both packages could provide it but RPM cannot define a priority for preferring one of two packages that provide the same symbol. Is that right, Jan or Ales? Or anything changed in that field? So, the current plan with a new MySQL package will result in much more cleaner solution and should avoid ambiguities. Regards, Honza Note: In case there are some reactions, I'd like to excuse myself that I'll be off-line for a few days now and won't be able to respond until Monday. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
