Bug#1000342: bullseye-pu: package mariadb-10.5 10.5.13-0+deb11u1
On Tue, 2021-12-07 at 08:10 -0800, Otto Kekäläinen wrote:
> > When we were faced with a similar situation for 10.3 last year, we
> > decided to proceed anyway as 10.5 was about to become the default
> > version and 10.3 was then removed from unstable shortly afterwards.
>
> True
>
> > Looking at the current status of the 10.6 packages in unstable, it
> > doesn't seem like we're in the same situation - there are build
> > failures on multiple architectures, for instance, and no packages
> > in testing yet. As such, I'm trying to gauge the likely timescales
> > involved, so that we can make the best decision for our users.
>
> There isn't currently any active contributors to 10.6 in Debian and I
> am changing apartments this week so I might not have time to address
> everything quickly. Time scale for 10.6 getting into Debian testing
> is probably several weeks.
Thanks for your candid answer, and sorry for not getting back to you
sooner.
We (SRM) discussed this amongst ourselves and don't really feel
comfortable with ignoring the potential version skew for a prolonged
period of time.
After some investigation, it doesn't look like a further upload of the
current 10.5 package to unstable would work as-is, because all mariadb-
10.X build a number of the same binary packages, including mariadb-
{common,client,server} and libmariadb3. This means that once a newer
major version is uploaded to unstable, no further uploads of the
previous version are possible, which isn't ideal when the older version
is still the default.
Some of these issues could be avoided by moving most of the common
packages to a new source package, e.g. mariadb-defaults, in a similar
fashion to the existing mysql-defaults package; that doesn't work quite
so well with libmariadb3, unfortunately.
Do newer upstream versions get much testing / feedback while in
unstable but not the default version? If not, it might be worth
considering a more common approach of uploading the newer version to
experimental instead, and then transitioning it to unstable once it is
ready to become the default version.
An approach along these lines could help unblock the current issue
here, but would obviously require an epoch to allow a newer 10.5 upload
to override the existing 10.6 packages.
Regards,
Adam
Reply to: