Re: Changes to make MySQL vs. MariaDB less confusing
- james.hoga...@gmail.com wrote: > From the first date Honza announced the intended feature we heard a > lot of promises from Oracle about how they would act with stewardship > but words are cheap - so far in all this time there's been little of > any actual substance. I get the feeling the discussion is about maintainership, but taking over maintainership has not been an issue. Honza is the maintainer. He's doing a good job, and last I heard he intends to continue doing so for a while. What we/I did for F19 was to help solve the problem at hand: Find a way to have both MySQL and MariaDB in Fedora. And it worked. Together we found a solution. While Honza is still the maintainer, Bjørn has stepped up to help with packaging. He has made the 5.6 package that is currently in review, and Honza is reviewing it. As part of this effort, we've also had engineers in the background fixing bugs to reduce the number of patches applied during packaging. If you want us to do more, please say so. We're happy to help out. 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: MySQL and MariaDB in Fedora
- hho...@redhat.com wrote:
> On 04/10/2013 02:34 PM, Norvald Ryeng wrote:
> > - hho...@redhat.com wrote:
> >
> >> On 04/05/2013 08:06 PM, Norvald Ryeng wrote:
> >>> - hho...@redhat.com wrote:
> >>>
> >>>> On 03/21/2013 08:36 PM, Norvald Ryeng wrote:
> >>>>> What is the deadline for fixing the remaining issues with MySQL and
> >>>>> MariaDB in Fedora? We would like to find a solution and get 5.6 in
> >>>>> soon.
> >>>>
> >>>> Hi Norvald,
> >>>>
> >>>> I've just asked for creating component community-mysql, as discussed on
> >>>> fedora-devel above, the review is done already. As soon as it is built
> >>>> in koji I'm going to EOL MySQL component. So I'm expecting to be done in
> >>>> the beginning of the next week.
> >>>
> >>> I see you've bumped the epoch of the MariaDB packages to force
> >> MariaDB as default when both MySQL and MariaDB provide mysql-server.
> >> We've tested it, and it seems to do the trick.
> >>>
> >>> Could you rename the MySQL packages to mysql-community-* instead of
> >> community-mysql-*? That way the prefix aligns with the product name
> >> and OpenSuSE's prefix.
> >>
> >> I wanted to use that, but then found out that it wouldn't work. The
> >> problem is that it has the same prefix as virtual name "mysql", that is
> >> used as requirement in other packages. As a result, when somebody asked
> >> for "mysql" -- "mysql-community" would be preferred before mariadb,
> >> because according [1] rule #9 ("check the prefix of the pkg to the
> >> requiring pkg prefix (perl-foo and perl-lib) for each common character
> >>
> >> in the prefix add 2 points to the provider's score") would be
> >> applied.
> >>
> >> When we use the name "community-mysql" we don't have any same prefix, so
> >> the rule #10 is applied ("if, at this point, we have pkgs with an equal
> >> score - look at the version of the provide"), which means mariadb with
> >> higher epoch will be chosen.
> >
> > We've tested and found that if the MariaDB packages have a higher
> epoch number, they will be chosen even if the MySQL packages have a
> "mysql-community" prefix.
>
> According to what I read in [1], mysql-community would be preferred
> before mariadb because of common prefix, in case both packages will have
> the same score from the previous rules.
>
> I've tested that with a potential package mysqlfoo, which has the same
>
> prefix as mysql-community, so if I ran:
>
> $ yum update mysqlfoo
>
> then mysql-community got higher score and was preferred before mariadb.
>
> Maybe there are even more cases like that, so I'd rather stick with
> community-mysql.
>
> [1] http://yum.baseurl.org/wiki/CompareProviders
We've tested and retested. With versioned provides and epoch bump, MariaDB is
preferred, regardless of the name of the MySQL packages.
> >> Generally, I don't like either, that packages in openSUSE an Fedora
> >> won't have the same name, but openSUSE has a bit more powerful RPM spec
> >> to handle such things.
> >>
> >> [1] http://yum.baseurl.org/wiki/CompareProviders
> >>
> >>> How do we get push access to the git repo? It would be great to get
> >> 5.6 in before the test day on April 30.
> >>
> >> To get involved, just follow standard process as described on Fedora
> >> wiki:
> >> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
> >>
> >> However, I'd rather wait with 5.6 until F20 because of the following
> >> reasons:
> >> * we are almost a month after feature freeze
> >> * I believe users will have enough concerns with switching to MariaDB
> >> and MySQL-5.6 would bring others
> >> * better wait a bit longer to stabilize the new release than bring a
> >> quite important package too soon
> >
> > Introduction of MariaDB should not interfere with upgrading MySQL.
> If anything, choosing MariaDB as the default makes upgrading MySQL
> easier since it will only be installed when users explicitly ask for
> it.
>
> Upgrades like this are usually considered as a Feature, which also
> corresponds with Feature description at [2]. Therefore I'd rather wait
>
> for F20.
>
> [2] https://fedoraproject.org/wiki/Features/Policy/Definitions
Since MariaDB is now the default, I don't see how MySQL upgrades need a feature
request by these definitions. If you look at the feature request history, there
are only a few upgrade features. Most software is upgraded without a feature
request. I couldn't find any feature requests for previous MySQL upgrades.
Regards,
Norvald H. Ryeng
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MySQL and MariaDB in Fedora
- hho...@redhat.com wrote:
> On 04/05/2013 08:06 PM, Norvald Ryeng wrote:
> > - hho...@redhat.com wrote:
> >
> >> On 03/21/2013 08:36 PM, Norvald Ryeng wrote:
> >>> What is the deadline for fixing the remaining issues with MySQL and
> >>> MariaDB in Fedora? We would like to find a solution and get 5.6 in
> >>> soon.
> >>
> >> Hi Norvald,
> >>
> >> I've just asked for creating component community-mysql, as discussed on
> >> fedora-devel above, the review is done already. As soon as it is built
> >> in koji I'm going to EOL MySQL component. So I'm expecting to be done in
> >> the beginning of the next week.
> >
> > I see you've bumped the epoch of the MariaDB packages to force
> MariaDB as default when both MySQL and MariaDB provide mysql-server.
> We've tested it, and it seems to do the trick.
> >
> > Could you rename the MySQL packages to mysql-community-* instead of
> community-mysql-*? That way the prefix aligns with the product name
> and OpenSuSE's prefix.
>
> I wanted to use that, but then found out that it wouldn't work. The
> problem is that it has the same prefix as virtual name "mysql", that is
> used as requirement in other packages. As a result, when somebody asked
> for "mysql" -- "mysql-community" would be preferred before mariadb,
> because according [1] rule #9 ("check the prefix of the pkg to the
> requiring pkg prefix (perl-foo and perl-lib) for each common character
>
> in the prefix add 2 points to the provider's score") would be
> applied.
>
> When we use the name "community-mysql" we don't have any same prefix, so
> the rule #10 is applied ("if, at this point, we have pkgs with an equal
> score - look at the version of the provide"), which means mariadb with
> higher epoch will be chosen.
We've tested and found that if the MariaDB packages have a higher epoch number,
they will be chosen even if the MySQL packages have a "mysql-community" prefix.
> Generally, I don't like either, that packages in openSUSE an Fedora
> won't have the same name, but openSUSE has a bit more powerful RPM spec
> to handle such things.
>
> [1] http://yum.baseurl.org/wiki/CompareProviders
>
> > How do we get push access to the git repo? It would be great to get
> 5.6 in before the test day on April 30.
>
> To get involved, just follow standard process as described on Fedora
> wiki:
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
>
> However, I'd rather wait with 5.6 until F20 because of the following
> reasons:
> * we are almost a month after feature freeze
> * I believe users will have enough concerns with switching to MariaDB
> and MySQL-5.6 would bring others
> * better wait a bit longer to stabilize the new release than bring a
> quite important package too soon
Introduction of MariaDB should not interfere with upgrading MySQL. If anything,
choosing MariaDB as the default makes upgrading MySQL easier since it will only
be installed when users explicitly ask for it.
Regards,
Norvald H. Ryeng
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MySQL and MariaDB in Fedora
- hho...@redhat.com wrote: > On 03/21/2013 08:36 PM, Norvald Ryeng wrote: > > What is the deadline for fixing the remaining issues with MySQL and > > MariaDB in Fedora? We would like to find a solution and get 5.6 in > > soon. > > Hi Norvald, > > I've just asked for creating component community-mysql, as discussed on > fedora-devel above, the review is done already. As soon as it is built > in koji I'm going to EOL MySQL component. So I'm expecting to be done in > the beginning of the next week. I see you've bumped the epoch of the MariaDB packages to force MariaDB as default when both MySQL and MariaDB provide mysql-server. We've tested it, and it seems to do the trick. Could you rename the MySQL packages to mysql-community-* instead of community-mysql-*? That way the prefix aligns with the product name and OpenSuSE's prefix. How do we get push access to the git repo? It would be great to get 5.6 in before the test day on April 30. Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
On Fri, 2013-01-25 at 20:29 +0100, Remi Collet wrote: > Le 25/01/2013 19:46, Norvald Ryeng a écrit : > > Here's the bug: http://bugs.mysql.com/bug.php?id=68182 This bug has now been fixed and will be included in release 1.2.0. > So, a few questions ? > > - why do you publish "community" source tarball with non GPL > documentation inside ? > > We need to recreate a "nodocs" tarball for each version, nightmare > > Ex : mysql, mysql-workbench, ... > > For MW we even need to patch source to remove the local link to the non > GPL documentation (and use online documentation instead) > > http://pkgs.fedoraproject.org/cgit/mysql-workbench.git/plain/mysql-workbench-5.2.45-nodocs.patch We include the docs because they are useful to users downloading the software directly from dev.mysql.com, even if Fedora and other distros can't redistribute them. In Debian, recreating the tarball is done by the get-orig-source target in debian/rules, so the manual work has to be done only once. After that, it's all automatic. Is this different with RPMs in Fedora? > Ex mysql-utilities: > > - why do you forget to publish tarball of new release I'm not sure I understand. MySQL Utilities are included in the Workbench tarball, or you can get them from the bzr repo on Launchpad. > - why "mut" man page still install when this have been notified 1 year > ago to upstream (the command is not installed) ? This is filed as bug #68182 and will be included in release 1.2.0. > - why "mysqluc" command still totally broken / unusable despite this > have been notified months ago ? > > See gui-to...@lists.mysql.com archives. I'm told that this is already fixed and will be included in release 1.2.0. > P.S. who have signed the Oracle CLA, and try to work with upstream as Great! > much as possible... but when upstream don't seems to hear you... Not so great, but I hope you'll see improvement now that we have each other's e-mail addresses. Just e-mail me if there are any issues that we should address. Thank you for maintaining the packages! Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
- m...@zarb.org wrote: > So let's take a very narrow and specific example, and see what could you > do after the fact to make packagers life easier. > > While working with Remi on a package review[1], I was quite surprised to > see that one Oracle engineer created a internal bug for the inclusion of > a patch from a external community member, to be added to a free software > project. Here's the bug: http://bugs.mysql.com/bug.php?id=68182 We'll try to do better in the future. Have a nice weekend! Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
- fed...@famillecollet.com wrote: > Le 24/01/2013 02:49, Andrew Rist a écrit : > > We've been following the discussions to replace MySQL with MariaDB > ... > > /me speaking from my experience. > > I don't maintain MySQL, but various other mysql packages > (mysql-utilities, mysql-connector-python, mysql-workbench, ...). > > Maintaining Oracle stuff in Fedora becomes a nightmare. > > Every new release introduce new issues, mostly because there is a lack > of communication (upstream and downstream) Hi, I'm sorry to hear about the lack of communication. I'm a MySQL developer, and for the last year I've been working with different packagers. Linux distributions are an important part of our community, and we'd like very much to hear your feedback and help make package maintainers' lives easier. We've had a really constructive cooperation on MySQL with Debian and Ubuntu the last year, and I am hoping we can extend that to Fedora and other distributions. Please let me know how I can help and be a direct connection to MySQL Engineering, bypassing all the FUD currently out there. This goes for both MySQL Server and related packages, such as those you maintain. Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
