On Wed, 18 Jul 2012 22:44:57 +0200, Luca Capello wrote:
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.
You are right, will be better to make package more standard and
similarly other packages with dbconfig-common.
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.
Argh, this is a my fail!
dpkg-reconfigure correctly work if choose do not reinstall database.
It was because i try on not very clean system.
But this is don't solve this problem, because it can change database
parameters only with database reinstallation.
Yes, we can say reinstall to already existed database and then ignore
error about already existed tables, but, IMHO, it is better to change
config by hands and then run dpkg-reconfigure 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.
dbconfig-common can't rename database (#439080).
But changing /etc/dbconfig-common/*.conf files is not anything
incorrect.
As i understand, it is normal for dbconfig-common to make changes in
/etc/dbconfig-common/package.conf and then run dpkg-reconfigure package
without database reinstallation.
It is a ususal for all debian packages, that use dbconfig-common. Am i
right?
So, there best solution will be make bacula-dir.conf consistent on
dpkg-reconfigure.
We can do this by two methods:
1. dbconfig-common will generate additional file from template with
database parameters (dbc_generate_*) and include it from bacula-dir.conf
2. substitute variables itself. This is will be very simple, when we
migrate config files under ucf control.
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
--
with best regards,
Alexander Golovko
email: alexan...@ankalagon.ru
xmpp: alexan...@ankalagon.ru
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
