Hi, On Tue, 2008-07-01 at 08:39:14 +0200, Raphael Hertzog wrote: > On Tue, 01 Jul 2008, Guillem Jover wrote: > > > While I realize that using dpkg-divert on conffiles is an uncommon > > > practice, the current behavior is clearly wrong. > > > > > > I've attached a simple git patch against current head that fixes this. > > > > Thanks for the patch! There's a problem with it though, namenodetouse > > has as a side effect to activate a file trigger. I'll probably be moving > > the side effect outside that function before applying this patch. > > We still have to activate the file trigger if we're effectively modifying > the configuration file (i.e. in all cases except if the user decides to > keep the old file IMO).
This is already done in deferred_configure with explicit calls to trig_file_activate_byname() depending on the situation, although as Timothy mentioned all files get activated on unpack as well (and some again in process_archive()). The explicit handling at least misses the cases where the user might have edited the files while dpkg got backgrounded. But see below. > So it could be argued that it's right to activate the trigger. After all, > even if the user choose to keep the old configuration file, he might have > merged some of the changes by hand (using the spawned shell). Per the current spec configuration files are not guaranteed to be activated in that case. Also as per the spec again, file triggers might be activated even if they have not be modified. Anyway, in this case, I've not really liked that side effect introduced to namenodetouse, and there's only a handlful of calls to it, so removing the trigger activation from that function and moving it to the calling code is the clean thing to do anyway. After that, in the future trigger activation can be fine grained to really activate stuff that has been modified, which is not that difficult. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
