Re: Draft spec for new dpkg "triggers" feature

[Ian Jackson <ian@davenant.greenend.org.uk>]

Florent Rougon writes ("Re: Draft spec for new dpkg "triggers" feature"):
> First, thank you very much for writing up this detailed spec.

Thanks for your kind comments :-).

> I have a question similar to that asked by Andreas Barth. [stuff]

Hmm, an interesting question.

>  Well, actually, after rereading my message, the question is maybe
> not so good and the remainder of my mail is mostly useful for
> discussing with fellow TeX maintainers how to use the trigger
> mechanism for TeX stuff. The problem may apply to many other
> packages, though. I suggest you read the following paragraph, and
> then decide for yourself whether your want to read the rest. :)

I think we should consider your case carefully; you ought to be one of
the important users of triggers and if it doesn't suit you well then
perhaps the design is wrong.

Summarising your situation, with the names changed:

       base <-triggers- middle <-depends- topmost

>   (1) middle is unpacked, which activates a file trigger in [base];
>   (2) middle is configured;
>   (3) topmost is configured
>   (4) base eventually processes the trigger activated in step 1.
> 
> This is a problem for us TeX maintainers, because when 'topmost' is
> configured in step 3, 'middle' is not functional at all, as the
> trigger wasn't run yet.

Yes, I see the problem.

It's tempting to solve this by making middle be in a new `triggers for us
not yet run' state, thus causing topmost not to be configured.  That
state would have to be purely a dpkg bookkeeping measure, which
applies _after_ middle's postinst has been run.  middle wouldn't get
called again after the trigger as that would be circular.

This leads to this question: what if topmost wants to activate the
trigger too ?  That necessarily involves invoking the trigger twice.
Ideally the maintainer of topmost would gets to decide whether to
(a) invoke the trigger twice or (b) not require the trigger to be run
for topmost's postinst, but I can't see how to express that.


I think perhaps I need to back off a bit and consider what we're doing
here.  The basic idea is that we have some kind of required operation
ordering like this:


 Events perpetrated     Events perpetrated      Events perpetrated
  by `base'              by `middle'             by `top'

 installation of
  base's files

                        installation of
                         middle's files

                                                installation of
                                                 top's files
 basic configuration
  of base

 --- base is now working

                        configuration of middle
                         requires completion of
                        basic configuration
                         of base

 registration of middle
  with base
                        --- middle is now working

                                                configuration of top
                                                 requires middle
                                                 to be working


I think the fact that `middle is now working' is only really true
after the triggers have been run is the most convincing argument in
favour of this new state.

But, this new state is a bit problematic because it violates the
previously true constraint that there is a sane complete ordering of
dpkg states from least-working to most-working:

                        Depends: on this        postinst
                         package

 unpacked,              Not satisfied           Must yet be run
 failed-config, etc.

 triggered              Satisfied               Must yet be run

 needs-triggers-
  -in-other-packages-   Not satisfied           No action needed
  -to-be-run

 installed              Satisfied               No action needed
        
This leads to difficult questions: if a package is in n-t-i-o-p-t-b-r,
and one of its triggers is activated, which state does it go to ?  Yet
another new state `triggered-but-also-does-not-satisfy-dependencies'
which is much like `unpacked' ?

(Triggered packages need to satisfy dependencies for obvious reasons.)

To some extent this lack of monotonicity reflects reality, because the
one kind of not-workingness is `this package doesn't work' and the
other is `some other package doesn't work and we have to do something
about it'.

One thing that would convince me that this is right would be an
example that clearly shows that no matter how we represent it, dpkg
needs to distinguish all four of the above situations and that they
have to be recorded with (or be treated as if they belong to) that
package.


Other objections: the cycle detection may be more complicated; the
needing-other-packages'-trigger-runs is not a flag but a list of
relevant packages or relevant triggers or something (since, for
example, it has to survive transitions of the triggering package back
to unpacked or even half-unpacked).


Summary: I we need to think about this some more.

Ian.