On 03-07-13 09:58, Marc Haber wrote: >> I recently thought about it for cacti. Maybe you can find the answer here: >> http://anonscm.debian.org/gitweb/?p=pkg-cacti/cacti.git;a=commit;h=5c8640af6857fb5660d89e5291f84994c730b3da > > That code was only added in May, with 0.8.8a+dfsg-6, right? Do you > feel that it has gotten enough test coverage to snarf it yet? I don't know how much people tested it, but I did append a testing script to check for some cases. Yes, I did test it for the cases I could think of at the time. > Did you on purpose decide not to bomb out if the new file does already > exist? Yes. In my case it would mean that the admin already created a file with the proposed new name, AND left the old name in place. As these files are only in the "conf-available" folder, it doesn't hurt there. The admin seems to know what he is doing. This doesn't mean that it works for you though. >> One point I tried to assure is that maybe the admin has removed the file >> and you want to honor that (i.e. let ucf/ucfr know that the file is >> removed). Maybe it could be done better, but this seemed to work. > > Good point. > > The code you have written will probably ask the user a question about > $newfile and then zap the file. Is this intended? Why not ucf > --debconf-ok /dev/null $newfile? If I remember correctly, you don't get any question, because ucf considers the file new and does not need to ask anything. I would expect that this way (rm -f immediately afterwards) it does not matter what source you use, and yours might just be clearer at the intension. Could you test and let me know? Paul
Attachment:
signature.asc
Description: OpenPGP digital signature