Hi Klaus, It seems like this is getting emotional because we both have the idea that we are not understood. Either I am missing some of your points or you are missing some of mine (or both). I tried to respond to your remarks below, but I think I understand how you got into the current situation (bug fixed in 2010) and how to get out of it (manually change dbc_install=true). So unless your response convinces me otherwise, I think this is my last message to this bug report.
On 30-05-16 01:10, Klaus Ethgen wrote: > 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. Wow, I totally missed that. I reread the first part of the bug report, and it looks like you never allowed dbconfig-common to overwrite you database. Or do you mean with "killed" that the database wasn't upgraded? >> On 27-05-16 14:34, Klaus Ethgen wrote: >> 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. That may be a cause for confusion. No, dpkg-reconfigure will not ask every existing question. It merely enables you to reconfigure a package and to facilitate this it additionally sets DEBIAN_PRIORITY=low. But the questions asked during reconfigure may (and in the case of dbconfig-common are) different than during initial installation. >> 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. No dpkg-reconfigure is the wrong solution (until I implement something to fix this bug). Reconfigure is something different than installation. So the questions are different. And currently what you want is not possible with dpkg-reconfigure. You want to change the dbc_install variable to true and the only way to do that is to manually edit the configuration file. Apparently I haven't been able to explain this clearly to you, so I try again, dbc_install=true doesn't mean that your database is reinstalled. It only means that you allow dbconfig-common to handle database management. In the case of upgrades, that means that dbconfig-common can actually take care of the upgrade. In case of installation it means it can create the database. But as your package is already installed, that last case is not relevant at all. And during reconfigure with dpkg-reconfigure, it doesn't even matter what the settings are, because during reconfigure, no choices are made based on the old settings (that is the idea of reconfigure). > That was never made for migrating existing databases into this system. Yes it was. It was just not asking the right question at the time you saw the migration question. As explained, that has been fixed long time ago, but your configuration hasn't been changed. You could argue, that at the time, there should have been a "fix it" question, you do run unstable: this bug that you are experiencing never reached stable. So probably the maintainer at the time didn't think of, or didn't see the need, to actually do that because of the burden. > And more over, there was no way documented how to do it. Well, I'll do that here: manually change the configuration file in /etc/dbconfig-common/bacula.conf and set dbc_install=true. Sorry to say, but again, if you run unstable, you are supposed to be able to fix breakage when it happens. > Fact is that old bacula was able to do the migration of older databases > to new versions and the new system does not. It does, but it requires dbc_install to be true. If anything else, it will not do any upgrades, because it is told not to. > 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. You haven't convinced me of this. I think I have told you how to fix the situation. >>>>> 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????? No, what I mean is that when people opt-out during initial installation (yes, I know, not your case, but that is how you ended up in your situation because the fix in dbconfig-common was made just a couple of days after you migrated) it is uncommon that they want automatic support during upgrades. If they do, I don't think it is weird to expect manual actions. The problem is that you ended up in the "uncommon situation" due to a long fixed bug. I am extremely sorry to say, but that is also part of the risk of running unstable. > Database is to keep values. Agree. > Deleting the database is never a good option (except you did only play > around in the begin). Fully agree. That is why dbconfig-common is extremely careful not to do that without explicit confirmation by the administrator. > And when the topic and all documentation says that when one change that > parameter to true it will delete the database, Please show me where this is written. I will clone this bug and update the documentation. That clearly is a bug, because then the documentation and the implementation don't agree. > What now? Does this parameter do initial installation of the database? This parameter is *set* during initial installation, during reconfiguration IF you opt to replace your database and by manual action. The only thing this parameter "does" is enable dbconfig-common support. (Please read the variable name as dbc_support_enabled) > Does it delete it or not? No, dbconfig-common does not delete the database unless you explicitly tell dbconfig-common to delete your database. And during reconfigure it will do that regardless of the value of this variable if you answer yes to the question about reinstallation. > Does it do that when doing the configuration > via debian-config? It ONLY does that during reconfigure if the administrator says "yes" to the question about reinstallation of the database. > What is true now? As far as I can tell, the questions that are asked during debconf are correct. > Again: I used bacula in no time gap. You used bacule between the switch of bacula to dbconfig-common and the change in dbconfig-common to ask a better question during upgrades. That is the time gap I mean. You were just unlucky 6 years ago, and apparently it only shows now. > So I had have a productive database > before you came up with that dbc idea at all. I never came up with the dbc idea. I would be proud if I did, but I took over maintenance a long time after you ran in to this bug. >>> 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. Maybe I wasn't clear. Here and everywhere else I meant the same. > However, I just ask about handling the (not so seldom) usecase that > there _is_ already a productive database. Fully supported. Again, you are experiencing the results of a combination that was there only for a couple of days in 2010. > 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.) Just switch dbc_install to true and be done with it. Paul
signature.asc
Description: OpenPGP digital signature
