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

[Carsten Leonhardt]

Hi Adrian,

Adrian Bunk <bunk at debian.org> writes:

> On Mon, Jul 28, 2025 at 12:12:55PM +0200, Carsten Leonhardt wrote:
>>...
>> should we recommend upgrading to bacula from backports before the
>> dist-upgrade in the release notes? That will perform the database
>> upgrade and seems like an easy workaround.
>
> no, backports shouldn't become a requirement for a regular upgrade from 
> one release to the next release. It would also not make a difference 
> with the problem at hand that the user is forced to answer (or preseed
> a debconf answer) for something that is not necessary.

Note that I didn't write "requirement". The idea here was to *recommend*
decoupling the bacula database upgrade from the debian release
upgrade. That was an idea to address Chris' concers upthread.

> On Mon, Jul 21, 2025 at 06:44:17PM +0200, Carsten Leonhardt wrote:
>>...
>> B) Default to "Yes" (applies to all scenarios)
>>
>>   If we switch the default for all scenarios to "Yes, go ahead with the
>>   update", I fully expect to receive bug reports about failed upgrades
>>   and I can imagine the frustration of people with big installations
>>   that only notice hours (or days) later that the upgrade broke and they
>>   need to do a restore that can then take another few hours, just to get
>>   to the point where they started from.
>>...
>
> Is it true that they would "only notice hours (or days) later"?

Yes, if the database they have is big enough. See
https://alioth-lists.debian.net/pipermail/pkg-bacula-devel/2024-February/003373.html

> The expected error handling would be:
> 1. bacula-director-$db.postint fails, aborting the upgrade with a clear
>    error message for the administrator
> 2. administrator creates required space
> 3. attempting again to upgrade the package is successful and results in
>    a correctly upgraded database
>
> What actually matters is that this error handling works,
> since some users will always hit this problem no matter
> how often and how annoyingly you informed them.

Don't forget that dbconfig will already have altered the database. Just
adding space and running the upgrade again will fail.

Let's say the postinst fails. A recovery to the previous state of the
bacula database is necessary to get to the point where you can retry the
upgrade. In the case linked above, a dump+restore takes 9 hours.

It's also possible that the upgrade doesn't fail at all, but just hangs
with the database server waiting for more space to appear. I've seen
that happen with MariaDB/MySQL in other contexts, and killing the
database server process can then leave the database in an inconsistent
state that necessitates starting the database server in a recovery mode
and try to fix things, which isn't fun at all.

> Regarding bacula-common.preinst, it is much better for our users to read 
> the release notes once instead of having to deal with release notes in 
> the form of dozens of debconf questions on every single machine being 
> upgraded.
>
> debconf is for configuring packages, not for forcing information on users.
>
> It seems something has already been added to the release notes:
> https://www.debian.org/releases/trixie/release-notes/issues.html#bacula-director-database-schema-update-needs-large-amounts-of-disk-space-and-time
>
> Release notes and NEWS.Debian are for informing users, you already have 
> both of these now.

We ask for confirmation that the upgrade is possible, I think that's not
"forcing information on users".

Regards

Carsten