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

[Jonathan Nieder <jrnieder@gmail.com>]

Hi again,

Is your current code in a git repo somewhere?  I would like to try it
out, even if the filesystem layout might change later, to see what it
is like to use and if I run into any issues.

(I would be happy to see this move forward so that we can get some
experience using it before squeeze.)

sean finney wrote:
> On Thu, Nov 19, 2009 at 07:44:51AM +0100, Guillem Jover wrote:
>> On Mon, 2009-11-09 at 23:26:27 +0100, sean finney wrote:

>>> 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.
>> 
>> How so?
> 
> there's more operations where disk/inodes could run out and time during which
> the user/system could kill the process, etc.  and supporting being able to
> clean up from such a state seems a bit messy.  so i was thinking on a
> less granular level wrt overall conffile db state.  

I fear I am still missing something.  Current code:

	enter unpacked state
	for each conffile:
		update it in an idempotent way (deferred_configure_conffile)
	enter halfconfigured state
	run postinst
	update Config-Version

Updating the db on a conffile-by-conffile basis adds to the
deferred_configure_conffile() step, without destroying the idempotency
or safety.  During the loop, the conffile db is always in a valid
state, so there is nothing to clean up.  Some "current" entries belong
to the old version of the package and some to the new version.
Committing a db entry could not cause the system to run of
disk/inodes, since it is a rename(), which reuses the inode.

Maybe there is some reason to avoid letting the "current" db mix
entries from multiple versions of the package.  In this case, dpkg
_would_ need to commit the entire db at once.

	enter unpacked state
	for each conffile:
		update it in an idempotent way
	commit new current conffiledb in an idempotent way
	enter halfconfigured state
	run postinst
	update Config-Version

Commiting the conffiledb could mean something like this:

	rm -r current
	mv new current

But that is not idempotent (repeating it does just the wrong thing).
As you mentioned, it is easier and safer to maintain some notion of
the current version number (though a symlink, or another field in
status like Config-Version) and update that idempotently.

Would it make sense to make the commit happen after the postinst runs?
This is what it would mean to use Config-Version for this purpose.
Intuitively, it makes more sense to me to make the commit happen
earlier, once the old conffiles are not needed any more for a possible
three-way merge.

Does that make sense?

Jonathan