Re: Draft spec for new dpkg "triggers" feature (v2, repost)
Florent Rougon writes ("Re: Draft spec for new dpkg "triggers" feature (v2, repost)"):
> In general, I think your new triggers-awaited state that doesn't satisfy
> Depends dependencies addresses the concerns I expressed in February.
> Thanks. More precisely, here are my comments and questions.
Thanks.
> Ian Jackson <iwj@ubuntu.com> wrote:
> > Details - Overview table
> > ------------------------
> >
> > Status Pending Awaited Satisfies Remedy
> > triggers triggers Depends
...
> > t.-awaited no always No postinst triggered + fix awaited pkg(s)
> > t.-awaited yes always No fix awaited package(s)
>
> I believe that, in the last column, the last two lines should be swapped
...
Indeed. In fact I've changed the `yes' and `no' in the `Pending
triggers' column since the states are supposed generally to improve
going down the table.
> > postinst triggered "<trigger-name> <trigger-name> ..."
> > This will be attempted for each relevant package at the end of each
> > dpkg run;
>
> I'm not sure what "relevant" means here. E.g., if I do:
> dpkg -i foo.deb
> will dpkg try to process only pending triggers in which foo is
> interested, or pending triggers in any package?
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).
> If the answer is "in any package", I don't understand how this is going
> to solve the problems were are trying to avoid with scrollkeeper and the
> various TeX registration programs, unless you expect apt and similar to
> massively use --suppress-triggers when calling dpkg during an upgrade
> (but judging from the third paragraph of your "apt and aptitude"
> section, it seems you do *not* want apt and similar tools to call "dpkg
> --suppress-triggers --configure <package>").
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.
> > [ state diagram ]
>
> I don't see the new 'triggers-awaited' state in your schema (maybe you
> didn't want to update it before having enough positive comments...).
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.
> In order to ensure that nothing bad happens from "lost triggers" due
> to "installed -> config-failed -> installed" transitions of an
> interested package I, I's postinst must do all the necessary work when
> called with the "configure" argument; i.e., all the work that would
> have been done if the triggers missed by I when it was in state
> config-failed had been processed.
>
> (yes, this is a bit complex; if someone can rephrase it in a simpler
> way, that's fine with me)
Yes. See my reply to your other mail, which has what I think is a
better wording.
> > If the package is not in state `installed', `triggers-pending' or
> > `triggers-awaited' then pending triggers are not accumulated.
> > However, [if] such a package (between `half-installed' and `config-failed'
> > inclusive) declares some trigger interests then the triggering
> > packages *will* await their trigger processing (or removal).
>
> I don't understand. On the one hand, you say triggers are not
> accumulated, and on the other hand, you say some packages will await
> their processing. How is it possible? Will these packages await the
> _configuration_ of the packages interested in the triggers, rather than
> their processing of the (unaccumulated!) triggers?
Yes. That was unclear and I have fixed the wording.
> > Use of --suppress-triggers, or an explicit list of packages with
> > --triggers, may leave packages in the improper `triggers' state. This
>
> s/`triggers' state/`triggers-awaited' or `triggers-pending' states/
Yes.
> Again, as I understood it, there is no `triggers' state in version 2 of
> this spec, only `triggers-awaited' and `triggers-pending'. So, that
> would be `triggers-pending' here.
Yes.
> > Currently, every Gnome program which comes with some help installs the
> > help files in /usr/share/gnome/help and then in the postinst runs
> > scrollkeeper-update. scrollkeeper-update reads, parses and rewrites
> > some large xml files in /var/lib/scrollkeeper; currently this
> > occurs at every relevant package installation, upgrade or removal.
>
> 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 ?
> > 5. If there are any packages which do by hand what dh_scrollkeeper
> > does, change them not to call scrollkeeper-update and change their
> > dependency to refer to the triggers-interested scrollkeeper
> > version, or delete the dependency entirely.
>
> Since packages using dh_scrollkeeper are supposed to drop the dependency
> on scrollkeeper, to be consistent, we should request that "packages
> which do by hand what dh_scrollkeeper does" also drop the dependency.
Yes.
> [typos and grammar fixes]
Thanks.
> > During dpkg's running /var/lib/dpkg/triggers/Deferred is a list of the
> > triggers which have been requested by dpkg-trigger but not yet
> > incorporated in the status file. Each line is a trigger name followed
> > by one or more triggering package names.
>
> Erm, are you sure it's "one or more"? What happens if one simply runs
> dpkg-trigger without the --by-package option? In this case, I believe
> there is no triggering package to list, right?...
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.
> Doh, we're there, at last. Thanks for your work!
Thanks a lot for your detailed review!
Ian.
Reply to: