Trent W. Buck wrote: > While waiting for some long-running packages to build, I wondered if > debhelper would protect me from the following: > > 1. I run "debuild", then go to sleep; > > 2. I wake up the next day and, not realizing that debuild is still > running, initiate another "debuild" in the same working tree > without looking. > > 3. Results are unpredictable, e.g. non-idempotent scripts aren't run > exactly once. > > To test this, I created a stub dh(1)-based source package and ran > > screen debuild && screen debuild > > Most/all of the usual dh_foo scripts ran in both windows. > Some kind of locking would be useful to prevent this.
I don't think that debhelper is the right place to deal with this. 1. debhelper is not the first thing run during a package build, nor the last thing, so it cannot provide locking for the whole build. Even if debhelper did locking, running two concurrent builds could result in garbage getting into the debian diff. 2. debhelper is not a long-running process, so any locking it did would be file-based, and so prone to dangling lock files dpkg-buildpackage would appear to be the logical place to deal with this, as it meets the above criteria. -- see shy jo
signature.asc
Description: Digital signature
