[PATCH 0/4] order of operations in dpkg --configure
Jonathan Nieder wrote:
> Until then, let me compare the analogous moment in the current
> configure phase. (deferred_configure_conffile(), in configure.c)
>
> 1. if .dpkg-new file is missing, skip to the next conffile
> 2. compute .dpkg-new file hash
> 3. prompt the user for action
> 4. with user’s help, bring installed configuration file up to date:
> - if doing something complicated, let the user modify
> his own version. We’re not responsible for this. :)
> - if keeping the user’s version, remove the .dpkg-new
> - if using the package’s version, rename the .dpkg-new
> to replace the conffile
> 5. atomically write the saved .dpkg-new file hash to
> /var/lib/dpkg/status
>
> If dpkg is interrupted between steps 4 and 5, the .dpkg-new file hash
> is gone, and the conffile hash saved in status is the old one, meaning
> the user will be asked about the conffile in the next run. I’m not
> sure why the code is written this way. Why not save the hash between
> steps 3 and 4?
That is, how about something like this change?
It is split up into mini-patches for easier review. Patches 1-3 are
preparatory patches intended not to change behavior significantly, and
then patch 4 addresses the (theoretical) bug. If these look good, it
might make sense to apply them as one squashed patch (or it might not;
I never was very good at sculpting histories).
Unfortunately, this small change ends up adding many more lines than
it removes.
Jonathan Nieder (4):
dpkg --configure: plug a small memory leak
dpkg: (K)eep conffile: split rename into link + unlink
dpkg: (I)nstall conffile: split rename into link + unlink
Fix theoretical race condition in interrupted dpkg --configure
lib/dpkg/dpkg.h | 1 +
src/configure.c | 69 ++++++++++++++++++++++++++++++++++++------------------
src/remove.c | 7 ++++-
4 files changed, 56 insertions(+), 24 deletions(-)
Reply to: