F18 => F19 update adventures

Honza Horak hhorak at redhat.com
Wed Jun 12 12:24:43 UTC 2013

On 06/12/2013 02:40 AM, Adam Williamson wrote:
> On Tue, 2013-06-11 at 07:47 +0000, "J├│hann B. Gu├░mundsson" wrote:
>> On 06/11/2013 06:38 AM, James Hogarth wrote:
>>>> What do administrators have to do to prevent being migrated from
>>> mysql to mariadb on upgrades?
>>> If you would prefer to use community-mysql rather than follow onto
>>> MariaDB I suspect the safest thing would be take a backup (you do
>>> that anyway right?) and just doing this from the filesystem is
>>> probably the simplest way.
>>> Then use a supported method to upgrade to F19 ... Either remove
>>> mysql before this or remove mariadb after this.
>> For the first we should not be migrating users on upgrades to another
>> DB solution regardless if it's an fork or not of the already installed
>> DB and we continue to ship it, secondly if we *must* do that ( which
>> is it is not in this case since we are continuing to package and ship
>> mysql ) we should have an opt out way for administrators to do so at
>> upgrade time instead of having them to backtrack all the migration
>> steps and revert them followed by them finally having to remove
>> mariadb in this case an simply big fat warning presented at the end
>> user during the upgrade phaze which offers him to opt out migration
>> and continue to use MySQL...
> It's easy to say 'should' this and 'should' that and 'should' the other,
> but it's rather more difficult to _do_ it. RPM fundamentally just
> doesn't really give you the option of expressing the policy you suggest:
> we can't have mariadb obsolete mysql but also have some kind of get-out
> clause so people can override the obsolete and instead get
> community-mysql. At least, that's my understanding of how the mechanisms
> in question work. It just doesn't seem to be a thing that's possible.
> I think the best thing that would be possible would be to install
> community-mysql manually before triggering the rest of the upgrade, but
> dependencies might become an issue. I suppose we could provide a
> community-mysql package in F18 so people could switch to it before doing
> the upgrade, but its presence might confuse people who didn't understand
> the trick we were attempting.

I've tested two possible ways how to manage to not update to mariadb 
packages when upgrading to F19 (we can switch from mariadb to 
community-mysql after upgrade of course or uninstall mysql packages 
prior upgrading, which both work as well, but doesn't need to be enough 
for everyone).

Shortly, we can either disable mariadb* packages in yum.conf temporarily 
or, as Adam mentions, install community-mysql befere upgrading (it only 
requires newer glibc, which doesn't seem to be problem).

Both ways are now described in the feature page:


More information about the devel mailing list