[pkg-bacula-devel] Bug#825064: Bacula director does not start silently due to database mismatch

[Paul Gevers]

Hi all,

On 24-05-16 11:53, Carsten Leonhardt wrote:
> it would be very helpful if you - as the dbconfig-common maintainer -
> would be able to spare a few minutes to clear up the following issue,
> because the discussion is about dbconfig-common by now.

Sure.

> Klaus, the bug reporter, updated from bacula 7.0.5 to 7.4.0. This
> requires a database update.
> 
> The automatic database update did not happen for him. My opinion is that
> the reason is his setting dbc_install='false' in
> /etc/dbconfig-common/bacula-director-sqlite3.conf.

Indeed. That is the reason.

> Klaus is of the opinion that setting it to 'true' will reinstall the
> database on updates, for that he quotes the question about
> reinstallation asked when doing "dpkg-reconfigure <packagename>".

dbconfig-common will not reinstall the database on updates. If it ever
does that it is a grave bug. Klaus is right however that the database
can be reinstalled with dpkg-reconfigure, so you can loose the old
database that way, but that is intended behavior. The text he quotes is
however not the question that gets asked during upgrades. The text
during upgrades is given below and says nothing about reinstallation of
the database.

The reason why dbc_install=false drops the full support of
dbconfig-common is because that is the variable that is set during the
initial installation (and the only one if one opts-out of support). So
we need to check this before anything else. If you didn't want install
support, it doesn't make sense to ask if you want upgrade support.

The config file says this:
# dbc_install: configure database with dbconfig-common?
#              set to anything but "true" to opt out of assistance
dbc_install='$(dbc_sq_escape $dbc_install)'

It doesn't say anything about installing the database every time, nor
does the description say that it is valid for install only. I agree
however that the variable name may be misleading. I am NOT going to
change that however as that would be too likely to cause other bugs.
However, the description can be improved if we find the current text not
good enough. If we go that route, I would like to ask advice from
debian-l10n-english at l.d.o. On the other hand, typically those values get
set from the debconf questions, so those questions are more important
and we reviewed them multiple times.

Paul
Ps: note the remark about backups in the text below.

Text on upgrade:
_Description: Perform upgrade on database for ${pkg} with dbconfig-common?
 According to the maintainer for this package, database upgrade
 operations need to be performed on ${pkg}. Typically, this is due to
 changes in how a new upstream version of the package needs to store
 its data.
 .
 If you want to handle this process manually, you should
 refuse this option. Otherwise, you should choose this option.
 During the upgrade, a backup of the database will be made in
 /var/cache/dbconfig-common/backups, from which the database can
 be restored in the case of problems.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-bacula-devel/attachments/20160524/290db78c/attachment-0001.sig>