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(-) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
