Manoj Srivastava <[EMAIL PROTECTED]> writes: > Can emacsen common lock the dir (/var/lock/emacsen.lock) and > not only look for the dpkg lock but also itself? (put the process id > in there so that one may look for /proc/<pid> to see if the lock is > stale.
I thought about this, but unless you can actually hold up the dpkg run, you still have ugly cases. Consider: dpkg -i calc*.deb dpkg --purge calc If the purge is run while the install is still running, dpkg may yank files out from under running processes, something the people who wrote the upstream Makefiles, etc. weren't expecting. Is this dangerous? I don't know for sure, but it's certainly a potential source of trouble. > Maybe. (bbdb needs to be run whenever the status of vm > changes). Hmm. I am not sure how one may reliably fix this, without > an elaborate system of hooks (preferably implemented by > dpkg). However, again. this is a smaller problem. This is why I brought up that alternate proposal which relies on existing mechanisms and cooperation between add-on maintainers to solve this particular problem. Of course, as I outlined, this means that vm would have to contain bbdb related config calls, or bbdb would have to check its status at run-time, every time. The one thing my earlier proposal doesn't prevent is multiple redundant runs of a given install/removal, but though annoying, it shouldn't cause any functional problems. This could be avoided if dpkg stashed a timestamp when it started up. Then emacsen-common could use this (and a per/add-on package timestamp of its own) to keep from running package install/removes redundantly during a given run. > And then prior art may be used to leverage a change in dpkg ;-). :> -- Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
