Hi,
>>"Rob" == Rob Browning <[EMAIL PROTECTED]> writes:
Rob> I thought about this, but unless you can actually hold up the dpkg
Rob> run, you still have ugly cases. Consider:
Rob> dpkg -i calc*.deb
Rob> dpkg --purge calc
I see. Well, there are indeed cases in which things may mess
up -- but all that happens is the a compilation run fails (make sure
that all installed packages shall be compiled even if one fails). So,
the only package to fail to compile is the one you purged. I think
that is reasonable (I mean -- what else do you expect?)
Rob> This is why I brought up that alternate proposal which relies on
Rob> existing mechanisms and cooperation between add-on maintainers
Rob> to solve this particular problem. Of course, as I outlined,
Rob> this means that vm would have to contain bbdb related config
Rob> calls, or bbdb would have to check its status at run-time, every
Rob> time.
I think that since VM and bbdb are merely lightly coupled,
until we can implement hooks into dpkg runs, we should just implement
what we can. I still think that waiting for dpkg to finish and then
using tsort is a useful first step.
manoj
--
"In general, it is best to assume that the network is filled with
malevolent entities that will send in packets designed to have the
worst possible effect" the draft "Requirements for Internet Hosts"
RFC
Manoj Srivastava <[EMAIL PROTECTED]> <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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
