Raphael Hertzog writes ("Re: Bug#487637: config of triggers-awaited packages"):
> (Switching from bug 143307 to 487637)
...
> I tried to come up with a patch, see below. The nicest solution I found
> was to detect packages in triggerawaited status if we were asked to
> configure them, and to add to the process queue the packages that are
> providing the triggers (those listed in pkg->trigaw.head->pend). The
> changes you made, let process_queue() call trigproc() which will call
> trig_clear_awaiters() and resolve the situation.I can see what you're doing here but I think your patch has convinced me that we should take a different approach than the one I took in my previous patch for 143307 (sorry!). As I previously commented, the problem was this state: > > > Package: a > > > Triggers-Awaited: b > > > > > > Package: b > > > Status: ... installed This can only arise due to incompletely written changes to the on-disk status databases, because for the brief moments it is like this in dpkg's core itself onerr_abort is set. So instead of doing a null trigger processing step for b, why not simply forget about the triggers-awaited for a ? After all b's trigger processing must have succeeded earlier. This should probably be done in trig_incorporate. On the plus side this would be much less code than my previous patch and your fixup to it. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
