On 19 July 2012 09:01, AZ Imballaggi S.r.l. - Enrico Ghera <enr...@azimballaggi.com> wrote: > b) updates/upgrades: > * first of all dbconfig shoud read the package's conf, and generate a > new one for itself. > * update/upgrade package
I'm of an opinion db-config behaviour was as expected and correct to its design. While it's an awesome tool which greatly helps with upgrades, I actually would be tempted to say its fully automatic behaviour should be limited (and this limitation clearly communicated) to local database installations only. While it'd be great to have all the possible configurations supported, the list of things that can possibly go wrong with remote database is quite long and anyway, if users moves database to remote host you can't really treat this setup as "basic" anymore; user moves the database conciously and is supposed to update dbconfig configuration as a part of this move. My knowledge about dbconfig is not great, however reading packages configs doesn't sound like dbconfig's job to me. If we wanted to do this, again the list of things that can potentially go wrong is quite long, eg. what if I split bacula config into multiple files and include one from within another one? Should dbconfig read all of them? Some of them? If so, which ones? I think the correct tool for the job here would be Puppet, which could manage Bacula as well as dbconfig flat configuration file and change database location accordingly. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
