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

Adrian Bunk bunk at debian.org
Thu Jul 31 19:35:38 BST 2025


On Thu, Jul 31, 2025 at 10:35:18AM -0700, Otto Kekäläinen wrote:
> Hi!

Hi Otto!

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

When there are failures, it's not bad when this is immediately visible 
to the administrator.

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

That sounds like a bad idea to me.

The postinst will restart the service, which might start the migration 
in the background.

The migration might take a long time.

There is likely a recommendation to reboot when the package management 
system has finished upgrading all packages.

The administrator reboots, not being aware that a migration is still 
running in the background.

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

How do you restore anything from backups when the database of your 
backup server is broken?

cu
Adrian



More information about the pkg-mysql-maint mailing list