[pkg-bacula-devel] [bacula] 02/04: Move bscan into it's own package, making bacula-sd-DBTYPE obsolete

[Sven Hartge]

On 29.07.2016 22:17, Sven Hartge wrote:
> On 29.07.2016 11:20, Carsten Leonhardt wrote:
> 
>> I hope to have time for a last test today, then I'll upload this to
>> experimental.
> 
> I am right now testing the upgrade from 7.4.3-1 to 7.4.3-3 and will also
> test if the changing of DBTYPE works.

Right.

I have tested the following on a clean Debian Sid with bacula 7.4.3-1
from Unstable installed. This time I used an apt-repository and did not
use dpkg directly.

I first installed bacula using the bacula meta-package from Unstable,
which pulls in the sqlite3 variant.

Then I enabled my experimental repository and did "apt dist-upgrade".
This correctly pulled in the new bacula-director package, removed the
obsolete ones, installed the init-scripts and systemd services and
everything works.

I then installed bacula-director-pgsql, which removes the *-sqlite3
packages, deconfigures the old sqlite database, installs postgres-9.5
and the needed bacula-*-pgsql packages. Database configuration via
dbconfig works.

I now notice that needrestart wants to restart bacula-director after the
installation, because it detects the usage of the now-deleted sqlite3
library. If the director is not restarted after the change of DBTYPE, it
will not work. This has to be done in the postinst, but only if we come
from a package with a different DBTYPE then we are now. Could be
difficult to detect as this no package upgrade for dpkg but a remove and
an install of a different package. Also the restart-detection has to be
done in bacula-director, where the init-script is.

Next step is bacula-director-mysql. This also pulls in the correct
packages but fails at the end, because the Catalog-Configuration is
still for Postgres and does not contain the correct parameters for MySQL.

I don't know how to fix that, as a specific part of an already existing
file /etc/bacula/bacula-dir.conf has to be changed and we don't want to
mess with an already existing config file. It may even be impossible to
do the easy way if the config-file is a bit more complex. At my
work-place we use a very modular config-file which uses @includes to
pull in different parts like the client-definitions,
database-configuration, schedules, etc. all from different config files.

I am of the opinion right now, that if the admin decides to switch the
DBTYPE, then it is his duty to change the config-file to reflect that.
The packaging logic can only provide the initial configuration at first
installation, everything else would be too complex to do for such a
marginal use case.

Aside from that, the packaging is now in really good shape and all
dependencies work as they should.

Grüße,
Sven.



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