retitle 1109499 bacula-common: preinst intentionally aborts unattended upgrade of bacula-director
Hi, first off: let's be clear as to what is happening. We aren't "intentionally break"ing upgrades. Paul Gevers <elb...@debian.org> writes: > On Sun, 20 Jul 2025 12:27:53 +0200 Niels Thykier <ni...@thykier.net> wrote: >> Perharps debian-devel or other people that would be in similar >> situations can help. Concretely, I suspect the postgres/mariaDB >> maintainers would have been in a similar situation at some point (I >> think PostgreSQL has a yearly bump of data base format). Personally, >> I would probably reach out to the PostgreSQL maintainers / check the >> PG packaging. I think the following scenarios are relevant: 1) The database is on the same machine as bacula-director. a) We are running a production machine. b) We are running some automated QA tool. 2) The database is not on the same machine as bacula-director. I don't think there is any QA tool testing this scenario. I see the following ways forward: A) Keep the status quo 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. If the release team says this is the way to go, so be it. However, I note that so far this didn't happen. C) Try to check space on localhost (scenario 1) Check if the database server is "localhost", then try to determine if there is enough space and if yes, go ahead with the upgrade. If there doesn't seem to be enough space, warn the user and suggest to abort or continue. If the database server is not "localhost", warn the user and suggest to abort or continue (scenario 2). Automatically determining free space is probably tricky with several edge cases, especially when interesting mount points exist. D) Add exceptions for more QA tools (scenario 1b) > Maybe we can reduce the amount of people running into the scenario > where this is needed by giving sound upgrade instructions? Sven has submitted an addition to the release notes: https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/290 > Is the upgrade handled by dbconfig-common? I recall that will at least > dump the database before trying the upgrade and notify the user of > that in case of failures. Yes, it is handled by dbconfig-common (if the user didn't shoot themselves in the foot by opting out of all or part of it, like we sometimes see). Regards Carsten
