On Tue, 05 Mar 2013 19:14:25 +0100, Honza Horak <hhorak(a)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 <tgl(a)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",
>> etc, which simply conflicted with the Red Hat-supplied packages named
>> "mysql", "mysql-server", etc. Perhaps it would be best to
>> naming tradition, ie establish a new Oracle-maintained Fedora package
>> named "MySQL", instead of figuring out how to transition
>> of the "mysql" packages. This would give us some more wiggle room
>> 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
> 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  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 , 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
Norvald H. Ryeng