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

[Adrian Bunk]

On Fri, Aug 01, 2025 at 07:57:37PM +0200, Carsten Leonhardt wrote:
> Hi,

Hi Carsten,

>...
> I'm not a database expert, but my guess is that SQL statements do not
> result in atomic operations on disk.

a core feature of SQL databases is ACID (atomicity, consistency, 
isolation, durability).

And this is not limited to single SQL statements:

You can write any number of SQL statements between BEGIN and COMMIT,
and the database ensures that either all of them or none of them happen.

You can put a billion SQL statements in one transaction, and the database
ensures that at any point in time either all or none of them are visible.

This includes what is visible to other database users accessing the 
database at the same time.

> If the server runs out of space,
> loses power or whatever, the database will most probably be in an
> undefined state. I wouldn't know how to automatically recover and
> continue database operations from the point where it stopped.

In all the error scenarios you describe, the well-defined state of an 
SQL database is the state without the transaction.

I haven't checked what exactly Bacula does during a schema upgrade,
but what you write sounds as if the problem might not even exist.

>...
> > Do you really want to receive the Release Notes in the form of
> > 100 debconf questions you have to manually acknowledge on every
> > machine you upgrade?
> >
> > Users will just be annoyed and click through it without reading,
> > as is already common on the web.
> >
> > The user is supposed to read the Release Notes before upgrading,
> > if the user chooses not to read them that's not our problem.
> 
> As you can guess, I would appreciate getting warned about performing an
> operation that could possibly result in an outage of services on servers
> without a direct relation to the server I'm upgrading: There will be
> users with a dedicated database server. They can use it for more
> applications than just bacula. Even having a redundant database server
> setup wouldn't help.
> 
> Sure, we can choose to say it's the user's fault for not reading and
> remembering the release notes.
> 
> But my opinion is still to err on the safe side: abort while it's
> safe(r) to do so rather than running into an error condition that can be
> magnitudes harder to resolve, especially while your backup is out of
> order.

You are not erring on the safe side, you are making debconf unusable.

You want to click through hundreds of debconf confirmation messages on 
every machine you are upgrading?

Every maintainer with a package that has a NEWS.Debian might argue the 
same way you do, and additionally add a debconf confirmation.

You seem to think that among the ten thousands of packages in Debian 
your package is the one that is so super-important that it has to force 
its NEWS.Debian through debconf even on users who only want to see 
critical debconf quesions.

Depending on how you upgrade and how many machines you upgrade debconf 
can be quite annoying, the user either has to manually click through 
everything or preseed all answers.

A typical upgrade might upgrade several thousand packages.

debconf questions that are not necessary are a PITA for users,
don't punish everyone for users who did not read the Release Notes.

> Regards
> 
> Carsten

cu
Adrian