[debian-mysql] Bug#919395: Heads up to release team about MariadB 10.3

[Andreas Beckmann]

[ changed recients to #919395 (transition bug) + pkg-mysql-maint,
  dropping upstream developers ]

On 2019-01-18 11:44, Emilio Pozuelo Monfort wrote:
> The problem was that the old libdbd-mariadb-perl didn't work with the new
> mariadb-10.3, so without a Breaks relationship in mariadb-10.3, there was an
> autopkgtests regression that was blocking the mariadb-10.3 migration. Yes, a
> Breaks could have been added, but that would have caused extra delays and I
> wanted to avoid that.

That didn't work out:

Trying easy from autohinter: mariadb-10.3/1:10.3.12-1 mysql-defaults/1.0.5
start: 22+0: a-1:a-0:a-0:a-0:i-18:m-1:m-0:m-1:p-0:s-1
orig: 22+0: a-1:a-0:a-0:a-0:i-18:m-1:m-0:m-1:p-0:s-1
easy: 32+0: a-2:a-1:a-1:a-1:i-19:m-2:m-1:m-2:p-1:s-2
    * amd64: libmariadbclient-dev
    * arm64: libmariadbclient-dev
    * armel: libmariadbclient-dev
    * armhf: libmariadbclient-dev
    * i386: libmariadbclient-dev
    * mips: libmariadbclient-dev
    * mips64el: libmariadbclient-dev
    * mipsel: libmariadbclient-dev
    * ppc64el: libmariadbclient-dev
    * s390x: libmariadbclient-dev
FAILED

Is it possible to get this information earlier? I.e. before britney
attempts to migrate the package and produces the failure?
Perhaps by doing a britney "dry-run" attempting to migrate each package
from sid ignoring age values ... and then reporting in the PTS,tracker
"britney dry-run succeeded/failed (link to logfile)"

Getting back to the current case: I assume this is caused by
libmariadbclient-dev being turned into a virtual package provided by
libmariadb-dev. I'll test whether reintroducing a transitional package
would improve the situation. Might require a trip through NEW, though.
A transitional package would also be needed to provide a smooth upgrade
path for people that consciously installed libmariadbclient-dev in stretch.


Andreas