Re: Draft spec for new dpkg "triggers" feature (v2, repost)
Hi,
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...
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.
I'm reading the whole thread before replying in order to avoid making
duplicate comments, but will start with some points in this mail as it
is fresh in my mind, before proceeding with my own comments on the spec
(if anything significant is left). So, here we go.
Ian Jackson <ian@davenant.greenend.org.uk> wrote:
> No, because the deconfiguration of I does not cause deconfiguration of
> T. Dependencies are not transitively followed during deconfiguration.
> This is deliberate, as full maintenance of the invariant you are
> assuming (ie T -Depends-> I && not(installed(I)) => not(installed(T)))
> would often involve massive deconfiguration runs for simple updates
> (eg, consider a libc security update!)
>
> 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?
>> 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.
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.
> Right. I've changed this to:
>
> Configuration files (whether dpkg-handled conffiles or not), or any
> other files which are modifed at times other than package management,
^
i
> should not rely file triggers detecting all modifications; dpkg
^
on
> triggers are not a general mechanism for filesystem monitoring.
[...]
> Err, that's what that sentence says. Lines starting with # will be
> ignored ie they are comments.
That's what I understood from the spec. Maybe Frank was asking a side
question about comments in debian/control, as opposed to "in the control
file for triggers"?
Regards,
--
Florent
Reply to: