[debian-mysql] Bug#671115: Bug#671115: transition: mysql-5.5

[Clint Byrum]

Excerpts from Adam D. Barratt's message of Sat May 19 08:51:34 -0700 2012:
> On Tue, 2012-05-08 at 06:18 -0700, Clint Byrum wrote:
> > On May 8, 2012, at 2:04, Julien Cristau <jcristau at debian.org> wrote:
> > > On Tue, May  1, 2012 at 22:52:22 +0100, Nicholas Bamber wrote:
> > >> At some point we need to transition from mysql-5.1 to mysql-5.5. We
> > >> would like to do this before the freeze though we appreciate that time
> > >> is now short. We arrived at this position as the Debian MySQL Team became
> > >> increasingly understaffed. It is better now but not ideal.
> [...]
> > To be fair, this transition was already completed in Ubuntu and I
> > filed bugs against all packages that failed with patches. Most if not
> > all of these patches have been applied.
> > 
> > I would expect this transition to go quite smoothly and just to
> > require rebuilds given the  experience we had in Ubuntu.
> 
> The problem is that the recent set of php5 security updates are
> currently stuck in unstable, because they picked up a dependency on
> libmysqlclient18.
> 

For anything critical like the PHP update, would it be prudent to upload
a new one with the build dependency bumped back to libmysqlclient16-dev
so they can progress to testing independent of this transition?

> For most library transitions, this wouldn't be such a big problem as we
> could push the new version of the source in and have britney keep the
> old library around in testing for as long as there were
> reverse-dependencies; indeed there was some hope that with mysql-5.5
> being a separate source package, this would be even easier as the two
> source packages could co-exist.
> 
> However, it turns out that won't work - the 5.5 packages have:
> 
> Breaks: mysql-client-5.1 (<< 5.5), mysql-server-5.1 (<< 5.5),
> mysql-server-core-5.1 (<< 5.5)
> 

mysql-common >> 5.5 will break 5.1 because there are new configuration
options used in /etc/mysql/my.cnf that will *break* mysql 5.1, as in,
it will refuse to run, libmysqlclient will throw errors, etc. This is
an unfortunate, but necessary evil.

We can upload a version of 5.1 that has no mysql-server, mysql-client,
or mysql-testsuite packages, and also that depends on a mysql-common-5.1
which breaks/replaces mysql-common << ${binary:Version}, and conflicts
with mysql-common >> ${binary:Version}, so that everything remains
installable during the transition. mysql-common in 5.5 would also then
need a Breaks/Replaces of that package to handle upgrades properly.

> and there are no versions of those packages with versions >= 5.5 (so I'm
> not entirely sure what the logic behind the version constraints is).
> Various -5.1 packages have versioned dependencies on other binaries from
> that source, which means we can't even mitigate the problem by adding
> Provides from the 5.5 packages.  Providing them as real transitional
> packages from the 5.5 source would probably work, unless there's some
> reason that's a crazy suggestion?
> 
> (There's also a mysql-5.1 upload which can't migrate to testing, as
> britney is convinced that it needs mysql-5.5 to migrate first;
> presumably because the latter now provides the
> mysql-{client,common,server} binary packages in unstable.)

The above idea would allow testing users to get the new 5.1 updates
while we finish the 5.5 transition. I'm not sure how important that is.

Perhaps I don't understand the transition process though.. how long will
it actually take? I'm really sorry for the total lack of understanding of
that process.. in Ubuntu where we don't have maintainers, I completed it
in about 2 days of no change rebuilds, and 1 day of patching the obvious
FTBFS's. The rest of the transition was actually fixing the 2 or 3 big
incompatibilities. With all of that work already done and those patches
submitted to all the Debian packages/upstreams/etc., I'd expect things to
go more smoothly in Debian. I understand there are more architectures, but
will it really take so long that we need to keep the 5.1 packages healthy?