Re: [PATCH 3/6] Conffile database handling functions

[Jonathan Nieder <jrnieder@gmail.com>]

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