[debian-mysql] mysql-5.6 -> unstable

[Clint Byrum]

Excerpts from Norvald H. Ryeng's message of 2015-06-12 00:07:52 -0700:
> 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.
> 

Actually ideally we'd just want to prevent the maintainer scripts from
doing so. If a user manually tries, we should just let it go forward, as
that script should be providing the user with enough information about
why it fails, if it fails.

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

Right, though that is not my idea, but it is what I agree is the right
path. :)