Hi Otto, Otto Kekäläinen <[email protected]> writes:
> I skimmed through https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109499 > quickly and my initial thought here is that Bacula (or any other program) > should not rely on dpkg maintainer scripts to upgrade the database as there > isn't any guarantees about what the initial state is, and if anything fails > it's really hard to restart or recover. Any failures happening during a > dpkg run in general will block the upgrades/installs/uninstalls for the > whole system as apt will refuse to do any new actions until the pending > dpkg package action has completed successfully. > > Instead I would recommend to do the upgrade as part of the systemd/init > service startup sequence. If it fails it's much easier to restart and debug > and the failure will only affect one single service, not the whole OS > package management system. Doing an upgrade check and upgrading the > database as part of the startup sequence will also behave correctly if the > user is for example restoring an old database from backups and trying to > start it with a new version of Bacula. the bacula packages switched to using dbconfig-common in 2006 and that's probably about as long as I've been a user of them. Since then, there haven't been any of the problems you describe (at least as far as I am aware - I only became maintainer of bacula in 2016). I think we can say that the current method for upgrading using dbconfig-common is well tested and in no need of change. On the other hand, I concur with Adrian that starting the dist-upgrade with a stopped MariaDB-server may break all packages that need to do database changes during their upgrades. Paul is the maintainer of dbconfig-common, maybe he knows more of its failure mode. Regards Carsten
