-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi,
Am Di den 31. Mai 2016 um 19:38 schrieb Paul Gevers: > 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. Maybe. Lets see. Do you have a link to that 2010 bug? > 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? Sorry, here I did overreact a bit. It didn't kill my database factically as I did not approve to kill it. The question in debconf is about killing the database and I never would allow that. There is nothing about using dbc at all. Nor does it mention that the killing of the database is needed to enable dbc, nor it it mentioned that without allowing dbc to kill your database you will not get further database updates as you got in the past with bacula upgrades. The sentence was meant that it would have killed my database when I allowed that to do so as it was suggested by you. I try to explain that the best I can but I am no native English speaker. > >> 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. Hmmm... New to me. This is the first time someone mention that. I always got the same questions with dpkg-reconfigure that I get with the initial installation. Nevertheless, I am pretty sure that the first question was the same -- Do you want to purge your database -- as it was the one I posted. Maybe the wording was different but not the content. Although, there is no way to prove that. > >> 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. See above. > 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. I don't want to set that _variable_ to true, I just want dbc to do the db-upgrades (or any other tool/script). And I do want (and I think, that is the expected behaviour) that I should not have to manually edit a file for a tool that does a job that was done without that tool before and the tool is only for this single job. See, changing that variable is an easy thing. But the logic behind is just wrong. debconf should ask the questions: - - Would you like to enable dbc? - - Would you like to initially purge your database and start from scratch with dbc? - - Would you like dbc to upgrade the database in future? But what you implemented was something like the following: - - Would you like to dbc purge your database and manage it afterwards? - - Would you like to dbc upgrade it then? You made the second question in fact depending to the first answered with "yes". But nobody, who is clear in his mind would answer this question with "yes". But most people would answer the last with "yes". So, having three variables, dbc_enable, dbc_install, dbc_upgrade which repesent my questions above is the correct solution. This is easily possible in debconf. And it solves all trouble that finally ended in this bug. > 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). Wait, does that mean that I can use dpkg-reconfigure now and enable that killing option and it would not kill my database? Or is it only possible to archive that by editing that file and set a misleading variable to true? Both feels very wrong. Nevertheless, I believe you now that at least manually changing that variable does no harm. But still, this is a ticking timebomb. I believe there are other out there who use bacula from before 2010 and opted out for database purging. > > 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, True. That I expected. > 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. Well, I use unstable on one side and stable with backports on a other side as I depend on features, bacula had (at that time) only in unstable. That put me now to the situation (by the way), that I had to downgrade bacula on unstable to work with bacula on stable. But this is purely my problem; not nice but my problem. > > 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. That for sure. But finally it should end in a fix of the package. And believe me, I had much worse breaks in the past. That is one reason why I depend on a working backup. And that is one reason why I take the time reporting bugs and arguing here. (For example, udev is not upgradable anymore since months as it is broken in newer versions than 215-18, just to give an example what had killed my box on boot time from time to time. But here we have also the best example that a broken udev got into testing that is the next stable instead of getting fixed.) > > 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. That is what I see here. > >>>>> 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. [...] > > 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. Now, I start to understand your point. What you wanted to explain is the following: - - bacula is installed long ago - - bacula is updated with daily package changes - - one package had a bug that was fixed in the next package, ignoring the "damage" the previous package did - - end is that bacula stays with that intermediately change. Is that correct? > > Database is to keep values. > > Agree. Good. Cause that is the most important point of my arguing. > > 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. Well, I quoted the debconf question. Although it is in German it says exactly that. > > 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) Ok, I'll try. But why not using the names I suggested above? > > 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. Hmmm.. > > 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. So, never touch debconf for that dbc... > > 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. Ah, ok. I have a bad memory for names. With "you" I just addressed the one(s) that care about bacula maintenance. > > 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. :-D Regards Klaus - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <kl...@ethgen.ch> Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Charset: ISO-8859-1 iQGcBAEBCgAGBQJXTeupAAoJEKZ8CrGAGfasyvEL/3gDJryZlvWSLZ2qtOrtLcvN +fgOG+Kqqg92U2Fpce0pWsQUO4YSXYzcS5puEkqRVF4rKSmxcz3eff5vgV7Hjqna ru1eztXJ8IoQWyuEL2P1p8ryExNrcyLip/dRpOBVqrDr9+M+k5LCWnywcYb1Tc42 OQRrpzwDtRwfPjP2T82qbrPFOz4bWOQXF150PHXKXadtoVvZWwmDFiEz5AfMTGq+ bntmEN84L0Js1bm8TMcULVtq11mzvVHnVAipmPiQTYwy75os4BV3nlPhoenYCY7M 8CATYdz04ju8nBTh6raBFaTcwqblqA2hA4Smqvvr8+hmYVWBeikc3bmcHoP1c5g7 7JzYAsGfQMy8DmEAkPdFb8OVPL8I9mc3a9R17MdrhGd0VOyUgZ1nD+TROdcYFhiT PWx3zefCPfFNywKAZjFarGu8ISbbxTvNaP2fuVm0uTVFw49PbWFXAWwFm5JnzdeC eHYpJpqbV1Nbrqtnh9vkdY9ZScncvJ7ug6JUJFntQw== =SbQB -----END PGP SIGNATURE-----
