On Fri, May 12, 2017, at 17:30, Norvald H. Ryeng wrote: > On Fri, 12 May 2017 14:09:02 +0200 > Ondřej Surý <ond...@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ý <ond...@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
