[debian-mysql] default-mysql-* metapackage (Re: factoring out mysql-common)

[Otto Kekäläinen]

I decided to split this topic in it's own thread separate from the git
repo layout question..

2016-06-28 14:17 GMT+03:00 Robie Basak <robie.basak at ubuntu.com>:
> I would like us to conclude my question about whether we want to create
> extra metapackages though, as I don't think it's necessary. I'd rather
> see us make things simpler by turning virtual-mysql-* into metapackages
> that depend on our chosen default, renaming as necessary. Then we'd have
> less indirection.
>
> The name "default-mysql-server" doesn't make sense though if it is to be
> a metapackage that depends on "mariadb-server | mysql-server" since if a
> user is using mysql-server then it is no longer the default that is
> installed.

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.


This suggestion would mean in code this:

https://github.com/ottok/mariadb-10.0/commit/e162c743fcd59273ba948e19b71cb5ed5638f0f5

Or in short form:

debian$ grep -e Package -e Provides control
Package: libmariadbd18
Package: libmariadbd-dev
Package: mariadb-common
Package: mariadb-client-core-10.0
Provides: virtual-mysql-client-core, default-mysql-client-core
Package: mariadb-client-10.0
Provides: virtual-mysql-client, default-mysql-client
Package: mariadb-server-core-10.0
Provides: virtual-mysql-server-core, default-mysql-server-core
Package: mariadb-test
Provides: virtual-mysql-testsuite, default-mysql-testsuite
Package: mariadb-test-data
Package: mariadb-server-10.0
Provides: virtual-mysql-server, default-mysql-server
Package: mariadb-server
Package: mariadb-client


>> Do you plan to implement this or will we proceed otherwise?
>
> If we can resolve my question above, I'd be happy for us to upload
> something like this to experimental. I'm just about ready with an upload
> to experimental for 5.7 too (just need to clean up the changelog), so
> it'd be nice to test this all out there.

Great. Please proceed. I can help with uploading if needed.

>> Will you attend DebConf? I will and I will also have time for all
>> sorts of Debian work during that week if you want to collaborate on
>> something.
>
> FWIW, I won't be there, sorry. I hope that I can attend something in
> person in the future though, and in the meantime I'd be happy to join
> some kind of virtual sprint if that would be helpful.

If possible, please work on this topic on Monday and Tuesday morning,
and attend via video to the mysql/mariadb Debian maintenance BoF at
17:15-> South African time: https://debconf16.debconf.org/schedule/

The BoF is devoted to general discussion, attracking new contributors
and planning the future. So we should not eat up that session with
mysql.git repo layout or metapackage discussions, but get those
discussions concluded on this list before so we can proceed with other
issues.

- Otto