[debian-mysql] mysql-5.6 -> unstable

[Norvald H. Ryeng]

On Thu, 11 Jun 2015 16:22:42 +0200, Robie Basak <robie.basak at ubuntu.com>  
wrote:

> On Wed, Jun 10, 2015 at 02:18:58PM +0000, Bjoern Boschman wrote:
>> can anyone with upload rights pls upload mysql-5.6 to unstable?
>>
>> https://www.boschman.de/~jesusch/git/mysql/mysql-5.6_5.6.25-1_amd64.changes
>>
>> changes are commited and pushed to git.
>
> Please don't, it's broken. Have you actually build tested it?
>
> I have fixes/reversions in the pipeline. I should have them in git in
> the next few hours.
>
> However, based on experience from Ubuntu, I wonder if I should fix
> https://launchpad.net/bugs/1447944 before we upload, in order to break
> fewer users?
>
> In addition to that, any opinion on having a maintainer script disable
> the mysql service somehow if updating between releases and the
> maintainer script can detect that local configuration changes mean that
> mysqld cannot start, rather than failing the maintainer script and thus
> failing the upgrade? It seems to me that this would make for a better
> user experience. We can explain what happened in a critical debconf
> prompt, but at least this way it won't break the user's system (only
> the mysqld service).
>
> Something like creating /etc/mysql/my.cnf.migrated.disabled in this case
> (when my.cnf was previously modified and thus my.cnf.migrated is
> created) and if that file exists then the service can avoid starting
> mysqld.

So you don't want /etc/init.d/mysql start or service mysql start to start  
the server until that file is removed? I think that's a fair thing to do,  
but those commands should tell the user how to enable it again, and why it  
was disabled in the first place.

If the server can't start, I agree that it's better to not fail the  
postinst script. That just causes a mess, and it's almost impossible for  
the user to figure out why it failed or how to fix it. But if we, instead  
of failing, just skip some postinst steps, we have to tell the user how to  
execute those steps when the server is up and running.

I agree with Clint on using a critical message to warn the user.

Norvald