Re: Draft spec for new dpkg "triggers" feature (v2, repost)
We're getting there. :)
Ian Jackson <ian@davenant.greenend.org.uk> wrote:
> > I'm not sure what "relevant" means here. E.g., if I do:
[...]
> It will try to process triggers activated during that run. This
> includes:
> - triggers activated directly by foo
> - triggers activated by something else which happens in this run
> (eg deconfiguration or removal of some other package)
> - triggers in foo activated by other trigger processing being
> performed
>
> It generally doesn't include any triggers foo is interested in because
> during most of this operation foo in states similar to unpacked; foo's
> postinst is supposed to do whatever might be needed. The only case
> where this doesn't apply is where some other package's trigger
> processing, caused by the installation of foo and typically done after
> foo is configured, itself activates one of foo's triggers. Then foo's
> postinst would be run twice (or perhaps more times).
OK, that's clear. Did you clarify that in the text? Maybe the paragraph
I quoted just above is too much focused on explaining a corner case, but
at least a sentence like your "It will try to process triggers activated
during that [dpkg] run" seems necessary to me.
> apt doesn't do that. It configures packages in batches. And indeed
> for other reasons it ought to be taught not to try to tell dpkg which
> packages to configure.
Well, that's another debate I'm not really qualified to participate
in...
>> > [ state diagram ]
>>
> The difficulty with that is that triggers-awaited is a bit of an
> anomaly. It doesn't fit in just one box on the diagram - it overlays
> onto triggers-pending or installed. But I think it ouught to be
> mentioned there so I have updated the diagram.
OK.
>> Hmm, during my last upgrades, I've seen messages like:
>> Deferring scrollkepper update...
>> (quoting from memory; maybe the phrasing is different), so I'm wondering
>> whether it is still true that "currently this occurs at every relevant
>> package installation, upgrade or removal".
>
> Perhaps it defers it if scrollkeeper itself isn't configured or some
> other similar situation exists ?
Frankly, I have no idea. To be sure, one should have a close look at the
relevant maintainer scripts or more simply ask the scrollkeeper
maintainers...
> If you don't give the --by-package option and you're not a child of
> dpkg (which will have set an environment variable for dpkg-trigger's
> benefit) then dpkg-trigger will fail.
OK. Thanks!
--
Florent
Reply to: