Re: Draft spec for new dpkg "triggers" feature
Hi,
Ian Jackson <ian@davenant.greenend.org.uk> wrote:
> 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.
I agree with your summary, and the names you chose make it much easier
to follow, thanks.
[...]
> 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
>
ACK.
> 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.
Yup.
> But, this new state is a bit problematic because [...]
[...]
> 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' ?
Indeed, adding such a new state as n-t-i-o-p-t-b-r seems to bring a lot
of complications.
> (Triggered packages need to satisfy dependencies for obvious reasons.)
Ah! There we are. My previous mails were written under the assumption
that since packages in state "triggered" are not in state "installed",
they wouldn't satisfy dependencies. I therefore proposed to have topmost
depend on base to ensure that triggers are processed by base (during its
configuration process) *before* dpkg attempts to configure topmost.
So, that doesn't work. As for the "obvious reasons", I'd say:
- triggers have to be run late to be useful; this couldn't happen if
triggerred packages didn't satisfy dependencies;
- if triggerred packages didn't satisfy dependencies, then, suddenly,
whole chains of packages would have to be deconfigured whenever one
of their (recursive) dependencies is triggerred.
Right? Is there something else?
> Summary: I we need to think about this some more.
Schizophrenic? ;-)
--
Florent
Reply to: