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

[Otto Kekäläinen]

2018-03-16 2:58 GMT+02:00 Robie Basak <robie.basak at ubuntu.com>:
>> Yes, once an epoch is in the wild in Debian or Ubuntu, it's irreversible.
>> Others will simply need to follow suit.
>>
>> > If a PPA does not do this, then users will end up downgraded, with a
>> > failed data migration and therefore broken.  This is again unfortunate but
>> > I think acceptable: this is the risk of following a PPA.
>>
>> It's not clear to me that there is any risk of failed data migration, since
>> the versions involved are 10.1.29 and 10.1.28 - 10.2.7 is not in play.
>
> 10.2.x is in play in upstream's 10.2 apt repository for Artful, for
> example. A user who upgrades from there to Bionic will end up going
> backwards to 1:10.1.x[1]. To avoid this, I think external repositories
> will need to republish 10.2 and 10.3 with an epoch bump to all series,
> including for Artful, as well as for Bionic. Then the user will upgrade
> to 1:10.2.x while still on Artful, and so apt will then not attempt to
> "upgrade" to 1:10.1.x on upgrade to Bionic.

I think it is unfair that one single bad upload in Debian results in a
situation where all repositories in the world need to start using
epoch in all versions of MariaDB 10.1, 10.2, 10.3 (and any future
version) right now, then we assume everybody will upgrade their
packages to get a 1:10.x on their system just to prevent that a later
upgrade to Bionic will not suddenly downgrade their current 10.3 or
10.2 or 10.1 version to 1:10.1.x. In addition the all packaging
adopting this epoch, all control file stanzas referencing later than
or earlier than X will need to be refactored to say "requirement is
MariaDB 10.2 or newer, but not 1:10.1, and then 1:10.2 then again"
etc. I have not invested time in doing in figuring out the exact
details, so this example was just to illustrate the point, and might
not be fully correct.

I have owned several pre-installed Ubuntu laptops and all of them come
with their custom repositories pre-installed in
/etc/apt/sources.list.d/, which install custom versions of Linux
modules or whatever that are absolute requirements for those laptops
to fully work. There is no notion of "beta quality" or "risk" there.
When you for example browse Docker or LXC images they categorically
use 3rd party repositories to provide users with selected newer
software. I know there are _at least_ thousands of users who are
running in production Ubuntu version X plus newer releases of the LAMP
stack components. All of those 3rd party repos are production quality
and users most probably don't view them as a "risk" and a bad thing
they should not be using. Telling them that if they get hurt it is
their own fault is something I don't feel is the right thing to do. I
am now being told that the error has happened, and I and the rest of
the world just needs to "deal with it", but I find that mentally very
hard.