Bug#870253: clamav-milter: disengaging debconf management destroys config
On 2017-08-28 17:04:51 [+0900], Marc Dequènes (Duck) wrote: > Quack, Hi, > Thanks. > > I can help you test if you provide a test package. as you wish. At https://breakpoint.cc/clamav/ you can find a .dsc file of what we have currently in git on alioth and a prebuilt binary for amd64. > \_o< > Sebastian
Bug#870253: clamav-milter: disengaging debconf management destroys config
Quack, On 08/27/2017 04:56 AM, Sebastian Andrzej Siewior wrote: > I am going to drop that part where the debconf created file gets > overwritten with the sample file. Need to test before I commit it… Thanks. I can help you test if you provide a test package. \_o< signature.asc Description: OpenPGP digital signature
Processed: Re: Bug#870253: clamav-milter: disengaging debconf management destroys config
Processing commands for cont...@bugs.debian.org: > tags 870253 pending Bug #870253 [clamav-milter] clamav-milter: disengaging debconf management destroys config Added tag(s) pending. > End of message, stopping processing here. Please contact me if you need assistance. -- 870253: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870253 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#870253: clamav-milter: disengaging debconf management destroys config
On 2017-08-22 21:21:14 [+0200], To Marc Dequènes wrote: > @team: any opinion here? I am going to drop that part where the debconf created file gets overwritten with the sample file. Need to test before I commit it… Sebastian
Bug#870253: clamav-milter: disengaging debconf management destroys config
On 2017-08-22 16:52:12 [+0900], Marc Dequènes (Duck) wrote: > Quack, Hi, > This may be what people using ucf expect, and in this case you might > probably close the bug, but I don't find this a nice behavior. To me > disengaging debconf mean: leave as it is, I'll take care of it from now > on. I should at least have a choice even if the file was not modified > manually yet. The only change which I find legitimate is to remove the > "managed by debconf" header. @team: any opinion here? > Hope this is clearer. > > \_o< > Sebastian
Bug#870253: clamav-milter: disengaging debconf management destroys config
Quack, On 08/21/2017 01:53 AM, Sebastian Andrzej Siewior wrote: > So if I modify the .conf file only with debconf and then (later) tell > debconf not to handle it then the "old" .conf file will be replaced with > upstream's default one. That's precisely what I did not expect. I can find this upstream example in /usr/share/doc by myself, so I don't see the point in switching to it. It's not like it represents my previous version of the configuration saved when debconf took over (as there was none, first installation). One may wish to use debconf to draft a configuration and then disengage debconf to customize it but it's not possible directly. This may be what people using ucf expect, and in this case you might probably close the bug, but I don't find this a nice behavior. To me disengaging debconf mean: leave as it is, I'll take care of it from now on. I should at least have a choice even if the file was not modified manually yet. The only change which I find legitimate is to remove the "managed by debconf" header. Hope this is clearer. \_o< signature.asc Description: OpenPGP digital signature
Bug#870253: clamav-milter: disengaging debconf management destroys config
On 2017-07-31 19:38:58 [+0900], Marc Dequènes wrote: > Quack, Hi, > I configured this package using debconf and it worked nicely. I then wanted > to handle the file via configuration management and to do so I disengaged > debconf, replying "no" to the question "Handle the configuration file > automatically?" when doing a dpkg-reconfigure. > > The resulting message was: > Replacing config file /etc/clamav/clamav-milter.conf with new version > The configuration file previously created via debconf was simply replaced > without any backup, so all my config was lost (thanks backup). This should not happen. We use ucf for config file modification. I tried to reproduce this today. So if I modify the .conf file only with debconf and then (later) tell debconf not to handle it then the "old" .conf file will be replaced with upstream's default one. If you switch back to debconf then it should create the same config file (as it was before) because the settings stored in debconf are the same. Now. If you change the file manually (with the configuration management) and after that you tell debconf to not do anything then ucf should complain that the file was modified. I tried this scenario (make a local change, start debconf and answer the first question with 'no') and ucf complained as it should: |A new version |(/usr/share/doc/clamav-milter/examples/clamav-milter.conf.sample) of |configuration file /etc/clamav/clamav-milter.conf is available, but the |version installed currently has been locally modified. so that seems to work. You get |Replacing config file /etc/clamav/clamav-milter.conf with new version |Disabling old logrotate script for clamav-milter if you select "install the package maintainer's version" and if decide to select "keep the local version currently installed" then you only get |Disabling old logrotate script for clamav-milter So this what I had here. It seems to work as expected. Do you have some ucf auto-magic or did I misunderstand something. Sebastian
Bug#870253: clamav-milter: disengaging debconf management destroys config
Package: clamav-milter Version: 0.99.2+dfsg-6+b1 Severity: serious Quack, I configured this package using debconf and it worked nicely. I then wanted to handle the file via configuration management and to do so I disengaged debconf, replying "no" to the question "Handle the configuration file automatically?" when doing a dpkg-reconfigure. The resulting message was: Replacing config file /etc/clamav/clamav-milter.conf with new version The configuration file previously created via debconf was simply replaced without any backup, so all my config was lost (thanks backup). In accordance with the Debian Policy a package should not destroy user's config. In this case the headers saying this file is managed automatically should be removed but the configuration directives be preserved. You may also give a choice via a debconf question. Regards. -- Marc Dequènes
