[pkg-bacula-devel] Bug#923444: bacula: autopkgtest regressed in buster

[Carsten Leonhardt]

Hi Paul,

Paul Gevers <elbrus at debian.org> writes:

> 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.

I already found that we're not the first to run into this problem.

>> 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.

I haven't used triggers yet so I'm not aware of all the details. If we
can be sure that the setup will be executed even when no local database
server will be installed because a remote server is used, then I'm all
for doing it at the end.

>> 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?

Yes, we can live with that as long as the CI-people can, as Sven
already said.

Would you like me to file a wishlist bug against dbconfig-common?

 - Carsten