Re: [PATCH] dpkg: do not activate triggers for unchanged conffiles
Hi,
Guillem Jover wrote:
> On that specific case “cfo_keep | cfof_backup”, the user has been
> prompted, dpkg stopped, allowing to modify the installed conffile,
Thanks for the explanation. If no one else beats me to it, I’ll
write a comment to that effect tomorrow.
> through dpkg spawning a shell or backgrounding itself, or through
> another external means. So dpkg does not currently have a way to track
> if the installed conffile got modified, and that's why the trigger.
Hmm. I’m imagining a fictional initramfs-tools package interested in
files installed or modified in /etc/initramfs-tools/hooks.
The initramfs has to be rebuilt to take any configuration change into
account. If the system administrator makes a configuration change
herself, she can be relied upon to run update-initramfs; on the other
hand, if the change occurs from a dpkg run, dpkg is responsible for
running update-initramfs.
What happens if the sysadmin makes a change but forgets to run
update-initramfs? dpkg may or may not run update-initramfs; we can
only _expect_ it to if it changes the conffile itself.
The relevant question, then, is whether the conffile changes during
("because of") the dpkg run. Maybe it would be worth saving the
file’s hash or stat information before passing control to the user?
I was hoping this would convince me we need to remember the old
installed (resolved) conffile, but no such luck. If the conffile has
changed since the last upgrade, that might only indicate that the
sysadmin modified it between upgrades.
Good night,
Jonathan
Reply to: