[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