Re: Changes to make MySQL vs. MariaDB less confusing
On Mon, 26 Aug 2013 22:57:27 +0200, Ken Dreyer ktdre...@ktdreyer.com wrote: On Fri, Aug 23, 2013 at 9:34 AM, Norvald Ryeng norvald.ry...@oracle.com wrote: If you want us to do more, please say so. We're happy to help out. Thanks for extending the offer. Would you mind commenting on the mysql-workbench issues too? As Remi's pointed out a couple times, there's a long list of crasher bugs that have been filed with abrt in Bugzilla, and Remi has orphaned that package because it was too much work to remove the bundled libraries. I don't work on WB myself, so this is second hand info. I hope I'm not distorting it too much: As of WB 6.0, most bundled libraries have been removed. There are currently only two bundled libraries that are needed: scintilla and antlr-runtime. These are patched versions of the libraries that we haven't been able to get rid of yet. We're trying to, but we need to get some patches accepted upstream first. As I understand it, the current inflow of bugs is because WB in Fedora uses a non-bundled antlr-runtime. The bundled version includes at least one bugfix that is necessary for WB to work. This has been reported upstream and against the antlr3-C package in Fedora (bug #966973). Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Self introduction, and maintaining MySQL package
On Mon, 06 May 2013 16:42:43 +0200, Rahul Sundaram methe...@gmail.com wrote: Hi On Mon, May 6, 2013 at 4:13 AM, Norvald H. Ryeng wrote: I see review requests on the list for new packages that people want into F19, so I don't see how it could be too late for upgrading an existing package. I don't think it is too late to update MySQL but a new package isn't really comparable. If existing packages break in an update, that is far more problematic than a completely new package that a user has to choose to install. The existing mysql-* packages will be replaced by mariadb-* packages on upgrade, and mariadb-* will be the default when pulled in by dependencies. The community-mysql-* packages is something the user has to choose to install. Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self introduction, and maintaining MySQL package
On Fri, 03 May 2013 16:06:36 +0200, James Hogarth james.hoga...@gmail.com wrote: Please log this in the package review. Let's proceed with the rest of the review and look at renaming as a separate issue later. The current maintainers of community-mysql stated that their preference was to wait for F20 for community-msql 5.6 a couple of weeks back given that we are well past Feature Freeze, Branch, Alpha and only a few days off the Translation Deadline... If the renaming is to be left as a separate issue then what specifically is left for F19? The current maintainers have stated that they don't intend to maintain the package much longer, and we've volunteered to maintain it. Exactly how and when a transition of maintainership is done is still not decided, but please at least review our first package submission. We've been open about the intention to upgrade to 5.6 for months, but have respectfully waited to submit since the change of default has been difficult enough without introducing yet another variable into the equation. Now that the dust has settled and we seem to have a default selection that works, it's time to upgrade. I see review requests on the list for new packages that people want into F19, so I don't see how it could be too late for upgrading an existing package. Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self introduction, and maintaining MySQL package
On Fri, 03 May 2013 12:43:33 +0200, Bjorn Munch bjorn.mu...@oracle.com wrote: On 02/05 17.53, Honza Horak wrote: I have just submitted a request for rename of the package community-mysql back to mysql-community: However, I need to repeat that this could have some impact to choosing default package when asking for mysql name, as I've described at: http://lists.fedoraproject.org/pipermail/devel/2013-April/181340.html We have tried to reproduce this case here but we didn't get the wrong behaviour you refer to even with the name mysql-community. I don't why you are getting problems. We've managed to reproduce it now. This is currently only an issue for two pacakges: mysqltuner and mysqludf_xql. If the user doesn't have MySQL or MariaDB installed, MySQL is chosen. If one of the servers are already installed, it is not replaced. Please log this in the package review. Let's proceed with the rest of the review and look at renaming as a separate issue later. 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 hho...@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 hho...@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.kof...@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 -- 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 hho...@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 -- 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 hho...@redhat.com wrote: On 03/06/2013 02:44 PM, Miloslav Trmač wrote: On Wed, Mar 6, 2013 at 2:35 PM, Norvald H. Ryeng norvald.ry...@oracle.com 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: Building broken in rawhide for packages requiring mysql? Re: MySQL-libs conflicts with mariadb-libs-5.5.29-7.fc19.x86_64
On Tue, 12 Mar 2013 14:33:21 +0100, Honza Horak hho...@redhat.com wrote: On 03/12/2013 02:03 PM, Norvald H. Ryeng wrote: On Mon, 11 Mar 2013 19:00:29 +0100, Honza Horak hho...@redhat.com wrote: if I understand it correctly that the problem is caused by conflicting library names, then it should be solved today (the enhanced package is already building). Why not have non-conflicting library names? The APIs are different, so it makes sense to have both libmysqlclient.so and libmariadbclient.so. These can co-exist and applications can choose which library to build against. That would mean to persuade many depended projects to enhance their building configuration. Unless these projects start using some in-compatible features regularly, I don't think it would be worth changing the library name -- such projects currently don't care if it is build against mysql or mariadb. I believe both libraries should be installable and that the upstream projects and/or the maintainer of the package should choose which library to use. There are already API differences, so the libraries aren't fully interchangeable. The libraries are two different implementations of the same protocol. I don't see why they should use the same soname. With a parallel installation, a transition from one library to the other could be done gradually and controlled, one package at a time, with less risk of breakage. The solution that's currently implemented (bumping the version of the original libmysqlclient.so from 18 to 1018) is a hack and not a long-term solution. True, I'm expecting MySQL will be rebased to 5.6 and mariadb to 10.0 sooner or later and I don't believe that library versions will remain the same at that point. What does MySQL upstream actually plan with library version in 5.6? Is it going to be bumped? Yes, 5.6 will be in as soon as things settle and we find a workable solution for having both MariaDB and MySQL in the same distro. We already have 5.6.10 packaged. We're just waiting for package names, dependencies and everything else to settle. There's no need to mix yet another variable into the equation right now. It's complex enough without it. I'm not sure about the version number. I'll have to check with those responsible for the the client library. 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 hho...@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.kof...@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 -- 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 kevin.kof...@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 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 Mon, 11 Mar 2013 19:58:03 +0100, Kevin Kofler kevin.kof...@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_Cases_and_Solutions -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building broken in rawhide for packages requiring mysql? Re: MySQL-libs conflicts with mariadb-libs-5.5.29-7.fc19.x86_64
On Mon, 11 Mar 2013 19:00:29 +0100, Honza Horak hho...@redhat.com wrote: On 03/11/2013 06:55 PM, Sérgio Basto wrote: Hi , On Qua, 2013-03-06 at 09:25 -0600, Richard Shaw wrote: Looks like mariadb has hit rawhide now and I can't build mythtv. I've added conditionals for the direct mysql Requires and BR's but until some of the dependent packages are fixed, MySQL-python, qt4-mysql, etc. How (and when) we fix rawhide ? Thanks, Hi, if I understand it correctly that the problem is caused by conflicting library names, then it should be solved today (the enhanced package is already building). Why not have non-conflicting library names? The APIs are different, so it makes sense to have both libmysqlclient.so and libmariadbclient.so. These can co-exist and applications can choose which library to build against. The solution that's currently implemented (bumping the version of the original libmysqlclient.so from 18 to 1018) is a hack and not a long-term solution. Regards, Norvald H. Ryeng -- 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 hho...@redhat.com wrote: On 03/05/2013 11:07 AM, Norvald H. Ryeng wrote: On Thu, 14 Feb 2013 16:17:00 +0100, Tom Lane t...@redhat.com 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: Should MariaDB touch my.cnf in %post?
On Thu, 14 Feb 2013 16:17:00 +0100, Tom Lane t...@redhat.com wrote: Norvald H. Ryeng norvald.ry...@oracle.com writes: We want to keep the MySQL package in Fedora and are willing to co-maintain or take over maintainership if nobody else will do it. We haven't really discussed this with the current maintainers yet, but from the discussions on this list it seems they're not interested in maintaining the package after F19. If us stepping up changes that, we are happy to co-maintain. 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. 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. Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On Fri, 15 Feb 2013 03:30:01 +0100, Toshio Kuratomi a.bad...@gmail.com wrote: Norvald H. Ryeng norvald.ry...@oracle.com writes: On Thu, 14 Feb 2013 08:07:22 +0100, Rahul Sundaram methe...@gmail.com Well, unless Oracle as upstream wants to get involved as downstream maintainers in Fedora as well. They did offer to do that but don't seem to have stepped up yet. Let's do it now, then. :-) Hmm... I notice that you're not a packager in Fedora. Are any of ya'll that volunteered to take over the MySQL packaging Fedora Packagers? Neither Andrew or I will do the packaging. I'll be involved, but someone from our build team will do the actual packaging. None of us are Fedora packagers, so I guess we'll need someone to review our packaging and sponsor us. Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On Thu, 14 Feb 2013 08:07:22 +0100, Rahul Sundaram methe...@gmail.com wrote: Hi On Wed, Feb 13, 2013 at 10:26 PM, Kevin Kofler wrote: MariaDB WILL replace MySQL on upgrades. Well, unless Oracle as upstream wants to get involved as downstream maintainers in Fedora as well. They did offer to do that but don't seem to have stepped up yet. Let's do it now, then. :-) We want to keep the MySQL package in Fedora and are willing to co-maintain or take over maintainership if nobody else will do it. We haven't really discussed this with the current maintainers yet, but from the discussions on this list it seems they're not interested in maintaining the package after F19. If us stepping up changes that, we are happy to co-maintain. Any input on how we can and should proceed is welcome. Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
