-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Am So den 29. Mai 2016 um 20:25 schrieb Paul Gevers:
> Control: retitle -1 enable setting dbc_install during reconfigure
> Control: severity -1 minor
I still think that is a mayor error. It killed my database.
> On 27-05-16 14:34, Klaus Ethgen wrote:
> >> I am not sure if you are now talking about the current upgrade. If you
> >> are than that is correct, you didn't get the question because you had
> >> dbc_install=false. If you are talking about "ever" than something
> >> clearly failed during the migration.
> >
> > True, with upgrade I did not get any question.
> >
> > I got this (and only this) question when using dpkg-reconfigure.
>
> Sure, but dpkg-reconfigure will never apply upgrades from the past
I never claimed that.
> because it only applies the upgrades that are needed from YOUR old
> version to the current version. As the old version and the current
> version are the same, that would not make sense.
Well, you are wrong. dpkg-reconfigure asks every existing question. In
this case there is just only one in the present package.
> dpkg-reconfigure can sensibly only recreate the database from scratch
> or leave it alone. So dpkg-reconfigure is the wrong solution to the
> problem.
No, it is the right one. The questions, respective the configuring items
are wrong.
That was never made for migrating existing databases into this system.
And more over, there was no way documented how to do it.
Fact is that old bacula was able to do the migration of older databases
to new versions and the new system does not. So this is a complete
change of how it work. More over, dbc is completely useless except you
start using the bacula package _after_ dbc was stated to get used.
> >> As bacula migrated to
> >> dbconfig-common support for their MySQL and PostgreSQL databases way
> >> before that time (in 2006), I suspect you got the old (install) question
> >> and this would explain why you haven't seen the question in mentioned in
> >> my previous e-mail.
> >
> > Well, I do not know how long, but I use bacula for really long time now.
> > I have file dates up to begin of 2009 but using bacula much longer.
>
> Well, the bacula SQLite switch was done in version 3.0.3-3 (8 Feb 2010),
> so if you were following closely (have you always run your bacula on
> unstable), you may have been just in between.
Yes, I always run it on unstable. I was depending on settings that was
only available there.
And yes, I got that, that the dbc switch was done in 2010. And I
answered you that I use bacula from much longer before that date.
> >>> And that might be the problem.
> >
> >> Why?
> >
> > Well, I want to use the upgrade but not the install of a new database.
>
> Well, that is a uncommon situation,
Whut!?
Not deleting a existing database is a uncommon situation?????
> so you currently need to do some manual action, i.e. a change in a
> configuration file.
Even if I should do that, there was never a hint about that. And the
name of the relevant variable does say: "Never ever change me to true
if you want to keep your database!"
Sorry, but slowly that issue gets surreal. Database is to keep values.
Deleting the database is never a good option (except you did only play
around in the begin).
And when the topic and all documentation says that when one change that
parameter to true it will delete the database, then, I could not believe
that anybody would answer "yes" to that question.
> The point of confusion may be that database install in dbconfig-common
> only means initial install and possibly during reconfigure. Any other
> moment, dbconfig-common is not going to install anything, definitely
> not during upgrades.
What now? Does this parameter do initial installation of the database?
Does it delete it or not? Does it do that when doing the configuration
via debian-config? What is true now?
> >>> There was never a question about update.
> >
> >> As explained, with dbc_install=false that is to be expected.
> >
> > I mean, there as never a question about that even when dbc gots
> > installed in the begin.
>
> Sure, if you were just in the time gap mentioned before, that is understood.
Again: I used bacula in no time gap. I used it _bevore_ dbc was
invented. (At least for bacula) So I had have a productive database
before you came up with that dbc idea at all.
> > Well, from the user perspective, I just vote for not overwriting my
> > existing database. I did not get any question about migrating the
> > database. (That was working bevore bacula switched to dbc.)
>
> Again (except with dpkg-reconfigure) the existing database is never
> overwritten. I believe you are voting for an option during reconfigure
> to turn on upgrades again. I already accepted that as the description of
> this bug.
Well, ok, that sounds opposite to what you told above.
However, I just ask about handling the (not so seldom) usecase that
there _is_ already a productive database.
And in the current state, as the migration is already done (wrongly)
long in the past, use the decision in dbc_upgrade for upgrades and the
one in dbc_install for install. (And the relevant debconf questions
likewise.)
> >> The question it stands for is, "do you want dbconfig-common to manage
> >> the database on behalf of ${pkg}". And as already noted, the question
> >> that is actually asked has been changed more than 6 years ago.
> >
> > Well, it asked to purge my existing database.
>
> I assume you are talking about the reconfigure situation. That is
> designed behavior.
So, design behaviour is to just purge a productive database with no
other options?
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Charset: ISO-8859-1
iQGcBAEBCgAGBQJXS3brAAoJEKZ8CrGAGfasPkoL/1og0YrKvcKThaKkS822G9PG
G7fMBmfPBzfAOWbKD26jU3ZVR8loQcSPLAhxjI+sPfSC9a4ewbmaZlLFq+mZGtOF
DciaW3g98n7sZ1xt/yPqichtzli/xv1LKbj2COXptXLk+QIPRt8hYmHBlw2CMmL+
PxSLTc1EZh3BGQY4l+guqMz8volRNDMltHcar/h1qAZzC6hwJw6DrUTF+ef8DahW
UuflHdkAPVvWXLYXPK76XJWtoCLTasy4Zr4b+N2FVMUcOaaa9v5WgA4n8y6bRx5a
+epGYvqROzv70KNAW6W9LCD2AAq5T7PLk06mJ0Q6Ef+MzRKogzXU+M3K1KD+PAtM
1ILUjr91zyTsuT2YkFd1brVfFJIiBJFmBtu9/w09b7jDlW7Izzz8fOXOkltxet8G
tXyZsxkoR6Ip0t+D8eiy/v74vWh1pfuAD5rA0IXAtWM+/CrnOEcYvir9etKd61jQ
XjYN8yXI0W+5NQASBrO8AYBPqyUYLcMRV+hJjzNaCg==
=TCxY
-----END PGP SIGNATURE-----
