[debian-mysql] conf files decoupling (Re: On IRC?)

[Robie Basak]

Hi Otto,

On Sun, Feb 08, 2015 at 11:29:59AM +0200, Otto Kekäläinen wrote:
> > My mistake. I'll fix this.
> 
> I don't see any new commits in
> https://github.com/basak/debian-mysql/commits/master in February, do
> you do your fixes in some other location?

I haven't pushed a fix for this yet. Github is where I've been pushing,
but I have been rebasing my branch there.

> Ok, so to recap the policy we are now implementing:
> 1. Each variant registers their own /etc/mysql/my.cnf ->
> /etc/mysql/<variant>.cnf
> 2. The /etc/mysql/<variant>.cnf file can basically be almost empty but
> it makes sure that the configs in /etc/mysqlconf.d/*.cnf and
> /etc/mysql/<variant>.conf.d/*.cnf are loaded
> 3. Common and shared configs can continue to live in /etc/mysql/conf.d
> 4. Variant specific configs will live in /etc/mysql/<variant>.conf.d

Right. Thank you for summarising this.

> 5. If the confs in /etc/mysql/conf.d/*.cnf and
> /etc/mysql/<variant>.conf.d/*.cnf conflict, the per-variant files are
> read later and thus override any /conf.d/*.cnf definitions.

I hadn't really considered the conflict. But I think your description is
right, and so we should include the per-variant files later as you've
described.

> >> What do you mean "client can drop"? I've now put all MariaDB confs in
> >> mariadb.conf.d, both client and server.
> >
> > I mean that packaging (any package, any variant, even packages that
> > aren't MySQL variants such as tools) can then assume that placing
> > configuration files in conf.d/ will always work.
> >
> > It also gives users a place to put configuration that they want to
> > retain even when switching variants. This is effectively what they've
> > indicated by putting something in conf.d/ prior to this upgrade, and so
> > it's convenient that we maintain the same semantics afterwards too. This
> > makes it easier to not break users' customized configurations on the
> > upgrade, or in the future when switching variants.
> 
> OK. My recap above should reflect this.

Yes - I think we share the same understanding now - thanks.

> >> Ok, I removed the mv command and replaced with a simple echo notifying
> >> the user to check the config path.
> >
> > This is better, but doesn't it still cause a problem if the new
> > mariadb-server-10.0 is configured before the new mysql-common package?
> > A straightforward upgrade is the common case, and if you don't enforce
> > postinst ordering with the Depends then some number of these could
> > configure the other way. So it seems to me that a large proportion of
> > users will upgrade and then be without a symlink at all just because
> > dpkg happened to configure mariadb-server-10.0 first.
> 
> Hmm.. I should pin the mysql-common to be preconfigured first because
> a missing/old my.cnf would anyway break things.

I don't think a preconfigure (I presume you mean Pre-Depends?) is needed
here, just a Depends. Since unless there's a dependency loop packages
are configured with their dependencies resolved.

I wasn't sure why the Pre-Depends exists, so I just left it there
without worrying about it. Looking at it in more detail now, it seems to
me that it's needed for mysql-server-5.6.preinst (since a preinst won't
have normal Depends resolved at run time).

So: 1) I don't think the Pre-Depends needs to be bumped; and 2) a
versioned Depends on the mysql-common supporting this newer
configure-symlinks wrapper should be all that is required.

> I like the idea of having a bit of backwards compatibility and at the
> same time cater for new features (the goal here was to allow for per
> variant configs), so I'll try to think a bit more if I come up with an
> perfect solution here.

What don't you like about my proposed solution, that you would like to
change or find a better way?

Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/attachments/20150209/e68dafd1/attachment.sig>