[debian-mysql] On IRC?

[Robie Basak]

On Wed, Feb 04, 2015 at 07:30:14PM +0200, Otto Kekäläinen wrote:
> 2015-02-04 14:54 GMT+02:00 Robie Basak <robie.basak at canonical.com>:
> > On Tue, Feb 03, 2015 at 11:27:58PM +0200, Otto Kekäläinen wrote:
> >> Don't look at that, see
> >> https://github.com/ottok/mariadb-10.0/commit/d42fba6d08ee76b517655af7ebcd89693da39ea9
> >> instead.
> >
> > Thanks. This looks good. A couple of comments:
> >
> > Can you please also include /etc/mysql/conf.d/ in your
> > /etc/mysql/mariadb.cnf? Then packages supplying the client can drop
> > client configuration into there, and so can the user. It'll also mean
> > that any previous customised configuration will be carried forward
> > unaltered.
> 
> Your example https://github.com/basak/debian-mysql/blob/560c9c2609cbbb1d92b944428371ffb20a6608b9/debian/additions/mysql.cnf
> only includes /etc/mysql/mysql.conf.d not /etc/mysql/conf.d/. The
> plain conf.d is only called from the my.cnf.fallback

My mistake. I'll fix this.

> Are you sure the MariaDB package should include both mariadb.conf.d
> and conf.d? Isn't the point to create separation in the configs and
> not to permanently keep stuff in conf.d that all versions might read?
> Would it be better to do a one-time "cp -rf conf.d/* mariadb.conf.d"
> instead if we want to carry over old configs?

I think that the plan for carrying the configuration forwards must be
the same for all variants, to avoid complexity. Otherwise a user might
upgrade one variant and then switch to another and then the packaging
will fail to keep up.

It seems easiest to me to just leave conf.d/* alone, and include it.

> 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, 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.

IMHO, the only sensible way to do this is how I've done it in Oracle and
Percona - to depend on the newer mysql-common, and just call
configure-symlinks. I don't see any disadvantage to not doing this - we
just need to make sure that we upload the new mysql-common first, which
we can make sure to do.

(In Ubuntu, variants doing this would be held in vivid-proposed until
the newer mysql-common package is available anyway. I presume Debian
would hold things in unstable and not migrate to testing until this
happens also?)

> I am on a train and SSH does not work right now, I'll push the latest
> when I am at home. Please note that the repository has a master branch
> and a jessie branch. The changes I am now doing are on the master
> branch, which can be uploaded to Ubuntu or jessie+1.
> 
> Builds fail on Launchpad due to TokuDB tests failing. I cannot
> reproduce it on my local laptop or pbuilder server. I have asked
> TokuDB devs for help. If they don't reply soon I'll just disable
> TokuDB for now to get around it.
> 
> > What I'd like is to follow what we will have in Ubuntu (whether via
> > Debian or not) as soon as we're ready. Presumably this shouldn't regress
> > anything that you've done in Debian? Could you please point me to a tree
> > that has this, or maybe upload the proposed stuff to
> > ppa:mysql-ubuntu/collab so we can see all the pieces working together?
> > Then I can test some possibilities.
> 
> I will try my best but I have a big coding project deadline on Friday
> I must focus my time on to avoid big penalties. Feel free to open pull
> requests on my github if you want to tweak something.

OK. We're running out of time now though - we have only two weeks to
feature freeze in Ubuntu now. I understand that you're busy, but I think
I have to start uploading things to Ubuntu now in order to make Vivid.
This might involve me having to diverge mariadb-10.0 in Ubuntu. I'll try
to minimize impact which a view to syncing back in the future as much as
I can.