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

[Otto Kekäläinen]

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

If the server is not fully dedicated to just running Bacula, then
preventing dpkg/apt from doing anything is a bit overkill just for the
sake of notifying the user.

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

There are many ways to communicate things to the system admin, but if
they fail, the service would still restart the database schema
migration etc immediately after restart when the service file would
try to start Bacula and notice that upgrade wasn't completed.

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

We are now talking about Bacula's own database schema, right? For
example, if the hardware was broken and the sysadmin is installing
Trixie on a new host and installs the latest Bacula but takes the
Bacula database from the old Bookworm server, the Bacula schema would
never migrate if it only happens when triggered by dpkg. If it is part
of the service startup, it would always do the upgrade of the database
scheme when Bacula starts and it detects the stuff on the disk is of
an older format than what the running binary wants to use.