Re: Provides: emacsen ?
Hi,
>>"Rob" == Rob Browning <rlb@cs.utexas.edu> writes:
Rob> I have a couple of concerns.
Rob> First of all, what do you do about multiple dpkg runs. The
Rob> problem here is that (without support from dpkg), dpkg finishing
Rob> is not the same thing as all the install/remove scripts being
Rob> finished. So it would be a little tricky (and possibly
Rob> dangerous?) to allow a new invocation of dpkg before the old
Rob> scripts are finished.
Good question. However, this is a far smaller problem than
the one we face now, and any incremental improvement is better than
nothing.
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.
Rob> This also doesn't strictly address the issue concerning cases
Rob> where package A needs to have it's add-on package install script
Rob> re-run whenever package B is upgraded. I'm not sure this
Rob> matters though. Is this an issue?
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.
Rob> I'm also a little concerned about the re-inventing the wheel factor
Rob> here (doing things like our own dependencies) that might belong in a
Rob> more sophisticated dpkg).
Right. But changing dpkg has its own problems (like, time
taken to ;-). I think we should go ahead and implement this
functionality, flawed as it may be. And then prior art may be used to
leverage a change in dpkg ;-).
manoj
--
Anyone who knows history, particularly the history of Europe, will, I
think, recognize that the domination of education or of government by
any one particular religious faith is never a happy arrangement for
the people. Eleanor Roosevelt
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: