sean finney wrote:
> discussion:
>
> namely, while working on a conffile-by-conffile basis ensures atomicity
> at the file level, there's a bigger window where things can go wrong
> compared to renaming the directories.
I am not sure I understand this: isn’t configuring a new version
already an irreversible operation, since the conffiles themselves are
being overwritten in /etc? It seems relatively safe to me to move
each entry of the conffile db in deferred_configure_conffile() as soon
as it is no longer needed to help with that.
In other words, if the order of operations is:
check for .dpkg-new file
calculate .dpkg-new hash
if (new db entry absent)
save hash in status
delete .dpkg-new file
done
do 3-way merge (or whatever)
move new db entry to current
save hash in status
delete .dpkg-new file
then dpkg can be interrupted at any point without being put in an
inconsistent state, and the next run will recover appropriately from
that.
Complications:
- I am not sure how nice this would be for dealing with renamed
conffiles. Probably it is not worth worrying about that yet.
- Maybe some merge backends would want to work with all conffiles at
once. git, at least, works like this (though git itself probably
wouldn’t be using the conffile db). This seems too theoretical
to think about supporting yet, and it should not be totally
impossible to change the file layout later to support something
like this if needed.
But maybe multiarch changes everything. I dunno.
Jonathan
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
