[debian-mysql] default-mysql-* metapackages

[Andreas Beckmann]

On 2016-07-02 16:49, Otto Kekäläinen wrote:
> I guess I don't understand what this means. However after reviewing
> this more I decided my mind about the need for new metapackages.
> Unlike the Andreas current mysql-defaults.git/debian/control file
> suggestion, I don't think we should create 4 new metapages.
> 
> Instead I think the correct solution is to do like default-jdk does:
> introduce the default-mysql-* package names, which would now be
> provided by only mariadb-* packages (just like openjdk provides
> default-jdk) so there is no new actual meta packages to maintain but
> instead just a few purely virtual package names.
> 
> The virtual-mysql-* packages should stay and they should be used with
> the same logic as now. This enables other packagers to do choices, is
> backwards compatible and compatible with the debian package world
> outside official Debian repositories. I am sure everybody wants to
> keep user freedom and ability to still satisfy mysql dependencies with
> Oracle MySQL that provides virtual-mysql-* and not limit to only the
> default-mysql-* scheme that under current release team decision should
> be MariaDB only in Debian repositories.

TL;DR: Switching the default with virtual packages causes trouble on
distupgrades.
(Using (frequently) moving unique virtual packages to satisfy
Build-Depends works fine since the buildds don't do dist-upgrades in
their chroots (beyond the build-essential core). Using abi-hash virtual
packages (haskell, ocaml, ...) works fine, too, because they are unique
and don't move - they just appear/disappear.)


Unique virtual packages have a small disadvantage: you need to track
Breaks against every package that previously provided the unique virtual
package (to ensure it stays unique).

Virtual packages have another big disadvantage: they don't provide
upgrade paths. So users could end up with an old packages still being
installed after a dist-upgrade since it satisfies the dependency.

Let's say, we have in stretch:

	Package: foo
	Provides: default-foobar, virtual-foobar
	Conflicts: virtual-foobar

	# not built in stretch
	#Package: bar

	Package: f00b4r
	Provides: virtual-foobar
	Conflicts: virtual-foobar

	Package: baz
	Depends: default-foobar

and in buster:

	# not built in buster
	#Package: foo

	Package: bar
	Provides: default-foobar, virtual-foobar
	Breaks: foo
	Conflicts: virtual-foobar

	Package: f00b4r
	Provides: virtual-foobar
	Conflicts: virtual-foobar

	Package: baz
	Depends: default-foobar

Installing baz in stretch will pull in foo.
Distupgrading to buster will *not* install bar! The obsolete foo will
stay installed instead. (Unless some unlisted Depends/Breaks/Replaces
enforces the upgrade.) This is probably not what you want.

If you change baz to
	Depends: default-foobar | virtual-foobar
this could be acceptable behavior. But I still think that is wrong,
since it more or less switches the effective dependency from
default-foobar to virtual-foobar. We should keep the users on
default-foobar in regular upgrade scenarios.

Or what about

stretch:
	Package: foo
	Provides: default-foobar, virtual-foobar
	Conflicts: virtual-foobar

	Package: bar
	Provides: virtual-foobar
	Conflicts: virtual-foobar

buster:
	Package: foo
	Provides: virtual-foobar
	Conflicts: virtual-foobar

	Package: bar
	Provides: default-foobar, virtual-foobar
	Breaks: foo (<< buster)
	Conflicts: virtual-foobar

Install depends-on-default-foobar in stretch - what do you expect after
a distupgrade to buster? foo or bar?

So we should have a real package here:

	Package: default-foobar
	Depends: foo [squeeze], bar [buster]

Now an upgrade from stretch to buster with default-foobar installed
should also install bar and remove foo (or in the worst case *not
upgrade* default-foobar and keep foo installed - but default-foobar will
still be listed as an upgradable package).

IMO switching to a non-default provider of virtual-foobar should be a
manual admin decision consisting of
* removing default-foobar (real package)
* installing f00b4r (which causes removal of foo or bar)
and thereafter the admin is on his own for keeping virtual-foobar (which
could even come from a third-party repository) running.

I think the default-jdk approach (real package, the default regularily
changes with version bumps) fits mysql/mariadb better than the
default-mta approach (virtual package, I think the default hasn't
changed for some years, and the alternatives would be completely
independent implementations: exim/postfix/sendmail/qmail/...)


Andreas

PS: I have analyzed sufficiently many piuparts upgrade failure logs ...
trying to do fancy things with virtual packages causes trouble!