[pkg-bacula-devel] Bug#923444: bacula: autopkgtest regressed in buster
Paul Gevers
elbrus at debian.org
Sun Mar 3 13:32:43 GMT 2019
Hi Carsten,
On 02-03-2019 15:34, Carsten Leonhardt wrote:
> maybe using a trigger can help us:
This sounds like an idea we should try to implement in dbconfig-common,
to enable other packages to benefit from it as well. If done, this is
for after buster release though.
> In bacula-director-psql/mysql postinst, pseudo code:
>
> 1 if (database server is being installed in the same run)
> 2 then (install trigger to postpone database setup)
> 3 else (setup database now)
> 4 if triggered: (setup database now)
>
> Thoughts/explanations:
> Step 1: I haven't researched yet if it's possible to reliably detect
> that
> Step 3: set up now as we won't get triggered later
> Step 4: But what to trigger on exactly?
Why not delay configuration until the end in all cases? I don't like the
added complexity much, unless it has real value.
> An simple but stupid and unelegant alternative would be to generate meta
> packages "bacula-director-local-psql/mysql" that _depend_ on the database
> server packages.
I rather propose that we accept the current regression of the bacula
autopkgtest and we fix the situation properly (in autopkgtest and/or
dbconfig-common) after the buster release. Can you live with that?
Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-bacula-devel/attachments/20190303/9a89f8bb/attachment-0001.sig>
More information about the pkg-bacula-devel
mailing list