[pkg-bacula-devel] Bug#681790: Bug#681790: Bug#681790: /usr/sbin/bacula-dir: fails to upgrade database when database is on a remote machine

[Luca Capello]

Hi there!

Alexander, thank you for the detailed explanation, which means that this
bug should stay open (and retitled, in case).

On Wed, 18 Jul 2012 19:55:29 +0200, Alexander Golovko wrote:
> On Wed, 18 Jul 2012 18:35:07 +0200, AZ Imballaggi S.r.l. - Enrico
> Ghera wrote:
>> Il 18/07/2012 18:03, Luca Capello ha scritto:
>>> Hi there!
>>>
>>> On Wed, 18 Jul 2012 03:18:44 +0200, Alexander Golovko wrote:
>>>> So, this is not a bug in package, but dbconfig-common habits.
>>>> Ofcourse, we should describe database upgrade habits in
>>>> README.Debian
>>>> UPGRADE section.
>>> If you want to do that, then please go ahead, but strictly speaking
>>> this
>>> is not something that belongs to Debian, but in upstream manual.
>>> Debian
>>> provides a way to manage local and remote database, via
>>> dbconfig-common.
>>> If the admin changes that, than she/he should *know* that automatic
>>> upgrades could fail (Debian can not assure all possible
>>> configurations).
>
> We should describe differences from upstream - dbconfig-common usage
> and common troubles.

I slightly disagree, simply because dbconfig-common is the Debian way of
doing such things.  If we go on the path of documenting differences WRT
upstream, than each package using dbconfig-common should do the same,
which is IMHO plainly wrong.

> It is something difficult for me, because english is not native for
> me, but i will try later.

Do not worry for the language, having a not-completely-English
documentation is better than no documentation at all.

>>> Enrico, I am sorry for the bug, but I bet that having configured the
>>> remote database via dbconfig-common (thus via `dpkg-reconfigure
>>> bacula-director-mysql`) would have resulted in a correct upgrade.
>
> No, we should not use dpkg-reconfigure for change database parameters
> without database reinstallation.
> If we run dpkg-reconfigure, dbconfig ask to reinstall database and
> rewrite config file
> In choice of "don't reinstall database", dbconfig rewrite config file
> and add to it 'dbc_install=false', so this will stop future database
> upgrades.

IMHO this is a bug in dbconfig-common or in the way we use it, given
that we should be able to use it *without* database reinstallation.

>> just to understand better (and avoid other useless bug reports):
>> everytime I modify my database settings I should run
>> dpkg-reconfigure?
>> doing the work twice? (one for actual conf and one for dbconfig)
>> or I should run dpkg-reconfigure and it updates my conf as well?
>> or my brain is dead and I have not understood anything?
>
> If you change only database connect parameters (host, dbname, user,
> password, etc), than you should not run dpkg-reconfigure, but should
> make changes in two places:
> 1. in bacula config
> 2. in dbconfig files
> (/etc/dbconfig-common/bacula-director-(mysql|pgsql|sqlite3).conf

IMHO this is prone to errors, which is why I blindly thought that
dpkg-reconfigure would have done the trick.

Enrico, in the end you were right, which also means that you discovered
a bug in the Bacula packaging (or in dbconfig-common, I would say).

Thx, bye,
Gismo / Luca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-bacula-devel/attachments/20120718/a0f54eb2/attachment-0001.pgp>