Control: tags 802941 moreinfo Hi,
On Thu, 5 Nov 2015 09:26:06 +0100 Michal Čihař <ni...@debian.org> wrote: > Dne Sun, 25 Oct 2015 20:27:35 +0800 > 積丹尼 Dan Jacobson <jida...@jidanni.org> napsal(a): > > Please check first as the user might not always be running mysql at > > boot. > > > > Be sure your upgrade script is ready for the case when it isn't. > > > > E.g., pause and ask the user to start the server. > > This is something dbconfig-common could indeed handle more gracefully... If there is an issue, I agree that it is in dbconfig-common. I mark this bug as moreinfo because Dan should already know from our discussion in bug 801427¹ (from message 82 onwards) that he still needs to respond to my last question to him. Dan (or Michal if you want to contribute) please respond to the question below (which I copied here from message 114 in bug 801427 such that we can follow up with the discussion in this bug). Paul ¹https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801427#82 On 28-10-15 11:38, 積丹尼 Dan Jacobson wrote: > The problem is probably at the phpmyadmin upgrade script level, not > the debconf or whatever deep levels under the hood. Can't it e.g., > check if mysql is running, and then abort very early so that nothing > is tinkered with that will need sewing up? Yes it can check, but that doesn't help, as the upgrade process already started before ANY question or script by the package runs (all the required files are already unpacked on the system). Either the mysql server is running and everything is fine, or it isn't running and then what? Maybe the mysql database is not on the localhost (so it would need logic to detect that; can be done). Or it is not provided by mysql, but by e.g. MariaDB (I am not sure if that matters, so never mind). Now, let's assume that it detect all that stuff properly and now knows for sure that the database is not running but that it NEEDS to connect to the server to upgrade properly, because the database needs to match the already unpacked files on the system. It would need to raise the issue to error level to get the proper attention and that is exactly what dbconfig-common is already doing. Including providing you with all the options that I can think of to handle the situation: abort (such that you can easily retry once you fixed the underlying issue), ignore (such that the upgrade appears successful but you have to handle the situation manually outside of the upgrade tools view if you want your package to work properly), retry now during the upgrade (which allows you to start your server in the mean time such that the retry actually can succeed). What else do you desire?
signature.asc
Description: OpenPGP digital signature
