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

[AZ Imballaggi S.r.l. - Enrico Ghera]

Il 18/07/2012 22:44, Luca Capello ha scritto:
> 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.
I agree on this.
>>> 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.
also in my opinion doubling the places where to configure is too prone 
to errors. there should be a different way to make things, without doubling.
maybe each package that requires dbconfig shoud be able to read the 
package's conf files and generate automatically the dbconfig's conf.
it's a lot of effort but is transparent to users.

this is how I think it should work:
a) first installation:
     * run dbconfig asking wether to install on local machine or on 
remote one (also for new databases).
     * dbconfig shoud generate it's own conf files and place one example 
conf in the package's conf dir.
     * install package
b) updates/upgrades:
     * first of all dbconfig shoud read the package's conf, and generate 
a new one for itself.
     * update/upgrade package

this way if the sysadmin changes something in the package's conf on each 
subsequent upgrade/update dbconfig will find the right database.

anyhow the syntax of configuration files is quite stable... this should 
be a one time work.

> 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).
Wooo hooo! my first bug in Debian!
> Thx, bye,
> Gismo / Luca
thank you all.
Enrico