[ 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
