[debian-mysql] On IRC?

[Otto Kekäläinen]

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

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?

What do you mean "client can drop"? I've now put all MariaDB confs in
mariadb.conf.d, both client and server.

> Let's say that the upgrade decides to configure mariadb-server-10.0
> before configuring the new mysql-common. In this case, you'll rename
> my.cnf to my.cnf.old and create a symlink there. But won't the mv fail
> if my.cnf doesn't exist (eg. if the user removed it)? Also, what happens
> with the symlink when mysql-common is subsequently configured? My
> mysql-common upgrade path is careful to preserve the old configuration,
> but if you've renamed it to mysql.cnf.old it will not be used. I'd like
> to test this but am unable to build this right now. It seems to me that
> this logic adds unnecessary complication though. It increases the number
> of possibilities we need to consider and test.

Ok, I removed the mv command and replaced with a simple echo notifying
the user to check the config path.

> Commit d42fb doesn't seem to be part of your master github branch now
> (when I clone it I see it as a6c0a), and this seems diverged from what's
> in Debian. And when your upload to Debian is synced by Ubuntu, it's
> failing to build on amd64 due to test failures. So I'm finding it
> difficult to follow your work right now.

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.