Re: Provides: emacsen ?
Manoj Srivastava <srivasta@datasync.com> 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 <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: