[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Draft spec for new dpkg "triggers" feature (v2, repost)



Florent Rougon writes ("Re: Draft spec for new dpkg "triggers" feature (v2, repost)"):
> Sorry for answering so late. In the first weeks, I had difficulties
> allocating the appropriate chunk of time for rereading the whole
> document in good condictions, which then got mixed with laziness and
> procrastination...

No problem :-).

> I tried to explain that in private mail, but your (Ian's) MX was rather
> impolite and rejected my mail based on an RBL check.

Feel free to mail postmaster@chiark.  That bypasses the blocks and I
can make a hole for you in my spamfilter, or we can talk about mail
technicalities and the merits of the various spamfiltering approaches
if you prefer.  Nowadays it's an unfortunate fact of life that
antispam measures will occasionally block non-spam mail.

> Ian Jackson <ian@davenant.greenend.org.uk> wrote:
> > The reason it's not supposed to be a problem is that I's postinst is
> > supposed to deal with any dropped triggers when T is reconfigured.
> 
> I suppose you meant "when I is reconfigured" at the end, right?

Yes, sorry.

> >> I'm not sure how to rephrase the paragraph above.  Maybe add a short
> >> rationale like "triggered actions are considered unnecessary if the
> >> interested package I is not configured, and will be executed when I is
> >> later reinstalled or configured".
> >
> > That's an excellent sentence and I have cribbed it.  Thanks.
> 
> Hmm, as I understood it, I's postint will *not* be called with the
> "triggerred" argument in this case. It will be called with "configure"
> and the postinst is supposed to do whatever is necessary in this case to
> compensate for the triggers that were "missed" when he was in state
> config-failed.

Yes.

> If this is correct, then the sentence is misleading, in that it gives
> (me) the impression that the triggers were kept in a queue while I was
> in state config-failed and will be processed when I is configured (I's
> postinst being called with the argument "triggered"). As I understood
> it, this is not the case.

How about this:

 Or to put it another way, triggered actions are considered irrelevant
 if the interested package I is not configured.  When I's postinst is
 called with `configure', it must do whatever actions are necessary to
 deal with any trigger activations which might have occured since it
 was deconfigured.

>[typos]

Thanks.

Ian.



Reply to: