[debian-mysql] Redesigning the /var/lib/mysql/*.flag thing

Robie Basak robie.basak at canonical.com
Mon Oct 5 09:06:03 UTC 2015


On Fri, Oct 02, 2015 at 05:17:56PM +0300, Otto Kekäläinen wrote:
> Hello!
> 
> Any responses to this? I haven't got any replies and it is a month
> since I sent this.

Sorry, see my response below. I'm not treating this as a priority right
now because what I want to do to solve this problem involves the path
changes I want, and that would easiest be done after the 5.5->5.6
transition, a decision from the release team about the variants, etc, so
I didn't see the need in pushing for it yet.

> 2015-09-01 16:02 GMT+03:00 Otto Kek?l?inen <otto at seravo.fi>:
> > Hello!
> >
> > Last year (e.g. in [1]) I proposed that a high priority for
> > mysql/mariadb packaging would be to redesign the downgrade warning
> > flag thing. I'd say it is the root cause of 80 % of the bug reports on
> > Launchpad (see [2] and [3]).
> >
> > By far most users simply don't understand the warning and don't know
> > how to recover from it. Also the whole idea is rediculus, as dpkg is
> > not designed in any way to support aborting in the middle of
> > preinstall scripts. Dpkg just ends up in a conflicting state that
> > needs to be resolved with dpkg --configure -a (and sometimes that
> > isn't even enough).
> >
> > Also none of the graphical tools in Ubuntu support the dpkg abort
> > process in any sensible way.
> >
> > Please send in ideas on how to redesign it.

I still think this is fundamentally broken because we have multiple
packages and versions stepping all over the /var/lib/mysql directory. If
we kept the paths separate (per variant and disk version), then
upgrades could create new or rename old without issue, and subsequent
downgrades and crossgrades would also be able to decide whether to
(re)create new or rename old.

This would make the question of what to do with "downgrade warnings"
moot, because there would always be a upgrade/downgrade path that works.

I believe that the Postgres packaging does something similar (just for
versions, not variants), and I intend to investigate further when I get
to looking at this in more detail.

Separate from this I think that a user should always explicitly choose
before migrating data that cannot automatically be reverted when moving
between variants, but that would be easy enough to do with debconf if we
had separate variant and disk version directories.



More information about the pkg-mysql-maint mailing list