Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives

[Otto Kekäläinen]

Hello!

2018-03-11 20:14 GMT+02:00 Jeremy Bicha <jbicha at ubuntu.com>:
> On Sun, Mar 11, 2018 at 12:54 PM, Otto Kekäläinen <otto at ubuntu.com> wrote:
>> Yes, it is better to have a newer version, but that will not remove
>> the epoch thing, all the those epoch related problems will remain. The
>> package is from my point of view now sabotaged and I cannot fix it
>> because of the epoch.
>
> Ok, I see. But why can't you just add the epoch to the 10.2 and 10.3
> packages too?

1) Because the epoch is ugly, adding it was a quick hack and done for
other reasons than what the Debian policy defines the purpose of the
epoch is.

2) And I don't think it is not justified to ask the world to adapt to
this "bug" in packaging now and for all future versions forever. It
would make so much more sense to fix it at the root before it
propagates out in actual releases and starts to break installations.


> I mean I don't see any way you'll be able to fix this in Debian
> without keeping the epoch.
>
>> Because of the epoch, anybody running for example mariadb-server version 10.3.x will have
> their packages either break.
>
> mariadb 10.3 isn't in any Debian or Ubuntu release so that doesn't
> really matter. If people are installing beta versions of low-level
> stuff from third-party repositories, that's not really Ubuntu's
> problem.

I agree that the Debian policy is sacred, and that we can require the
world to follow it wherever somebody does any .deb packaging. The
policy changes and heavily discussed and reviewed and all happen
because of good reasons. However I don't agree that _any_ decision
done by _any_ Debian Developer is something that we can or should
require the whole world to adapt to. We have now at hand a mistake
done by a solo Debian Developer that needs to be fixed before it
spreads.

Regarding the "world" I argue that out there are a lot of perfectly
valid 3rd party repositories in production use offering MariaDB 10.1+
and we certainly do not want to cause them to downgrade to 10.1 when
upgrading to Bionic.
Heck, even anybody running Artful who now have
10.1.30-0ubuntu0.17.10.1 will downgrade to 1:10.1.29-6 with Bionic
(though that scenario has less severe consequences).


> Even 10.2 isn't in any *stable* release of Debian or Ubuntu, so people
> using it now have an unsupported system.

If somebody really has 10.2 installed and a database running, and now
run apt-get upgrade, their system will completely break when
1:10.1.29-6 is forced upon them. Yes, they have an unsupported system
now but will get it supported again if Ubuntu get's past this epoch
thing and normal new releases continue, or if those users switch to a
3rd party repository that provides 10.2 or newer.

The main point here is not the corner cases of somebody running Debian
unstable, testing, Ubuntu alpha, beta or so, but what is expected to
happen when Bionic is released and real production machines will start
upgrading to Bionic. Those numbers are big, and I expect massive
problems.

I know my request is exceptional, but it is not impossible. The
version string in Launchpad's database are after all just strings in a
database, and can be reset if there is enough will.

If resetting is surely totally impossible, then I would suggest that
you remove the package from Ubuntu Bionic completely. New users would
not be able to install it, but at least production systems upgrading
would not experience massive breakdown (just a warning that system
cannot be updated because of dependencies not satisfied).