[debian-mysql] Fixing the jessie->stretch upgrade path

[Ondřej Surý]

On Fri, May 12, 2017, at 17:30, Norvald H. Ryeng wrote:
> On Fri, 12 May 2017 14:09:02 +0200
> Ondřej Surý <ondrej at sury.org> wrote:
> 
> > On Fri, May 12, 2017, at 13:31, Norvald H. Ryeng wrote:
> > > On Fri, 12 May 2017 11:26:13 +0200
> > > Ondřej Surý <ondrej at sury.org> wrote:
> > >   
> > > > Dear release team and fellow MySQL/MariaDB maintainers,
> > > > 
> > > > the situation in stretch in regards to clean upgrade path from
> > > > jessie is a little bit unfortunate. It works for most cases when
> > > > something depends on default-mysql-server and pulls it as a
> > > > dependency. But in situations where mysql-server was the top
> > > > dependency, it simply uninstalls mysql-server-5.5 without any
> > > > replacement.
> > > > 
> > > > I understand the reasons why we are here, but the situation where
> > > > user needs to do:
> > > > apt-get update
> > > > # apt-get upgrade
> > > > apt-get install default-mysql-server
> > > > apt-get dist-upgrade
> > > > 
> > > > is very inconvenient for the users and I foresee this will cause
> > > > a lot of complaints, because it's quite common to run just
> > > > "mysql-server" on the server.
> > > > 
> > > > Therefore I am proposing a one time fix specifically targeted at
> > > > stretch. I would like to prepare 'mysql-transitional' package that
> > > > will create a couple of dummy/transitional packages structured
> > > > like this:
> > > > 
> > > > mysql-server depends on default-mysql-server
> > > > mysql-client depends on default-mysql-client
> > > > 
> > > > The version would be 5.5.999+mariadb, so it is always higher than
> > > > version in jessie, but always lower than version in sid, as I
> > > > don't want force epoch on mysql-5.7.  
> > > 
> > > I agree that this sounds like it will work for stretch, and it's
> > > much better than bumping epoch on mysql-5.7.
> > > 
> > > As you say, it's a one time fix, but I'm a bit concerned about what
> > > happens when those packages again are provided by MySQL. Let's think
> > > through what will happen in buster. There are three options:  
> > 
> > And all of them would be easily solved by having the
> > mariadb-server-10.X and mariadb-client-10.X Conflicts with
> > mysql-server and mysql-client.
> 
> And as long as MySQL and MariaDB are not co-installable, they should
> conflict. But below you say we must make the packages co-installable
> to have both I'm a bit confused. Can you please elaborate?

The other email in pkg-mysql clearly stated that MariaDB and MySQL
servers are diverging and if we provide *both* in stable Debian,
packages might need to make a choice. And if there's a package A that
depends[*] on mariadb-server and package B that depends[*] on
mysql-server you ideally want to be able to install both A and B on the
same system.

* depends as in verb, not Depends as in d/control statement

> > > 1) Buster contains only MariaDB. Will these packages also be in
> > > buster? If not, what happens on upgrade from stretch to buster?
> > > Will we have the same problem again?  
> > 
> > default-mysql-* will already be installed, it will pull new
> > mariadb-*-10.x packages and mysql-server/mysql-client will be removed.
> > Nothing must depend on mysql-server/mysql-client already, so those
> > will be just dangling packages ready to be removed.
> > 
> > > 2) Buster contains both MySQL and MariaDB. MariaDB is default. The
> > > mysql-server and mysql-client packages are provided by MySQL, but
> > > default-mysql-server and default-mysql-client point to MariaDB. How
> > > will the upgrade go? Some users have installed mysql-server or
> > > mysql-client explicitly, while others have installed a different
> > > package that depends on default-mysql-server or
> > > default-mysql-client.  
> > 
> > I don't think this is going to happen, but if it does, we will have to
> > make MariaDB and MySQL coinstallable with each other, because the
> > packages might depend on specific flavour.
> 
> The default is to include MySQL in buster. The release team only made a
> decision about stretch, so unless they make a new decision, MySQL will
> be in buster. Therefore, we have to handle this case.
> 
> That said, I definitely wouldn't mind making the packages
> co-installable, no matter what ends up in which version of Debian.

postgresql-* packages might be a good example how to handle this, but it
will be a lot of work, and somebody will have to write the handling
script for smooth changes from one version to other.

Cheers,
Ondrej