On Sat, 24 Sep 2011, James Vega wrote:
> dpkg-gencontrol generates a tempfile, debian/files.new, and then
> attempts to rename that back to debian/files when it's done generating
> the files.new. This can easily break when parallel builds are happening
> as independent dpkg-gencontrol runs may rename files.new out from
> underneath each other. This happened in a recent build of the Vim
> package[0].
I wonder what's the best way to fix this. Using flock() on
debian/files.new is not really enough since the file is renamed
at the end of the process.
Ideally we should use a persistent debian/files.lck that can be safely
flock()ed but this temporary file would not be cleaned by any current
package, meaning that it would lead to cruft in source packages.
The cleanest approach I see is to try to lock the file in a loop
until the file is still here (meaning there was no contention and thus
no other instance that dropped the file after we opened it and while we
were waiting for the lock):
while (1) {
open(LOCK, ">>", "debian/files.lck");
flock(LOCK, LOCK_EX);
last if -e "debian/files.lck";
close(LOCK);
}
# Put code updating debian/files here
unlink("debian/files.lck");
flock(LOCK, LOCK_UN);
close(LOCK);
(Ignore the lack of error checking, it's only to explain)
Does anyone see possible problems with this approach? Or has anyone
something cleaner to suggest?
Would it make sense to factorize the logic above in 2 functions
in Dpkg::Path?
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/go/ulule-rh/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
