[debian-mysql] Bug#1109499: Bug#1109499: bacula-director-sqlite3: fails to dist-upgrade from bookworm to trixie

[Carsten Leonhardt]

Hi Otto,

Otto Kekäläinen <otto at debian.org> 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