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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
