Re: Draft spec for new dpkg "triggers" feature (v2, repost)
Hi,
Again, sorry for the late reply.
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.
Ian Jackson <iwj@ubuntu.com> wrote:
> Details - Overview table
> ------------------------
>
> Status Pending Awaited Satisfies Remedy
> triggers triggers Depends
>
> unpacked never maybe No postinst configure
> c.-failed never maybe No postinst configure (when requested)
> 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
(or, equivalently, one could swap the "yes" and "no" in the second
column):
- if the package has no pending triggers, we don't want to run
"postinst triggered";
- if it has, we do.
[...]
> To restore a package in state `triggers-pending' to `installed', or to
> process pending triggers of a package with both pending and awaited
> triggers, dpkg will run the postinst script:
> 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?
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>").
The reason is that what often happens during an upgrade is the
following:
Setting up lmodern ($version) ...
-> runs update-updmap, mktexlsr and updmap-sys
[...]
Setting up other-font-package ($version) ...
-> *again* runs update-updmap, mktexlsr and updmap-sys
[...]
Setting up texlive-base-bin ($version) ...
-> again *runs* update-updmap, mktexlsr and updmap-sys
[ well, maybe that's tex-common and texlive-base-bin does things a bit
differently, but this is not important in this discussion ]
With triggers, we expect that the three actions (or at least those that
take significant time) will only be run *once* at the end when
texlive-base-bin is configured.
But, if dpkg processes the triggers in which texlive-base-bin is
interested as soon as apt runs "dpkg --configure lmodern", the game is
over: lmodern will cause texlive-base-bin to run the three commands, and
when apt does "dpkg --configure other-font-package" later, it will
*again* run them.
So, either there's something wrong in this reasoning, or the "each
relevant package" phrase above meant "each package with pending triggers
on which dpkg is acting _in this run_". In either case, please clarify.
[...]
>
> |
> V
> ,------------.
> | unpacked |
> `------------'
> |
> |
> (automatic)| ,----------.
> | | config- |
> | | failed |
> | `----------'
> | | ^
> | | |
> |,---<--' |
> | (user |
> postinst | request) |
>"configure" | | ,------------------.
> | | | triggers-pending |
> | | `------------------'
> |`----->------'| | ^
> | error | postinst | |
> | | "triggered" | | trigger(s)
> | | (automatic) | | activated
> | | | |
> | `-----<-----------'| |
> | error | |
> | | |
> V V |
> ,------------------------------------------------.
> | installed |
> `------------------------------------------------'
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...).
> Packages in `config-failed' or worse are never considered to have
> lists of pending triggers.
At first, I found this strange, like Frank, because we think "Oh, this
is a way triggers can get lost!". Now, I'm getting used to it, but if I
understood correctly, we should clarify a bit:
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)
[...]
> 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?
[...]
> 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/
(I suppose)
[...]
> Note that automatic package management tools which call dpkg (like apt
> and aptitude) should not attempt to configure individual packages in
> state `triggers' with dpkg --triggers <package>... or dpkg
^^^^^^^^^^^^^^^^
> --suppress-triggers --configure <package>..., or similar approaches.
> This would defeat dpkg's trigger cycle detection.
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.
[...]
> WORKED EXAMPLE - SCROLLKEEPER
> =============================
>
> 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".
[...]
> Existing packages which Depend on scrollkeeper (>= 3.8)
> because of dh_scrollkeeper or explicit calls to
> scrollkeeper-update should be modified not to Depend on
> scrollkeeper.
[...]
> 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.
> This not 100% in keeping with the full transition plan defined below:
^
is
> if a new gnome package is used with an old scrollkeeper, there is some
> possibility that the help will not properly be available.
[...]
> dpkg's prerm will check for attempts to downgrade while triggers are
> pending and refuse. (Since the new dpkg would be installed but then
> refuse to read the status file.) In case this is necessary a separate
> tool will be provided which will:
> * Put all with any pending triggers into state `config-failed'
^
packages
> and remove the list of pending triggers.
[...]
> 2. Update the consumer package:
> * Declare an interest in the trigger.
> * Declare a versioned dependency on a triggers-supporting dpkg.
> * In the postinst, arrange for the new `trigger' invocation to run
> update-consumer. (The consumer package's postinst will alread
^
y
> run update-consumer during configuration, and this should be
> retained.)
[...]
> Broken producer packages, and error reporting
> ---------------------------------------------
>
> Often trigger processing by will involve a central package
> registering, compiling or generally parsing some data provided by a
> leaf package.
I think the "by" in the first line of the paragraph should be
suppressed.
[...]
> 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?...
> /var/lib/dpkg/triggers/Lock is the fcntl lockfile for the trigger
> system. Processes hang onto this lock only briefly: dpkg-trigger
> to add new activations, or dpkg to incorporate activations (and
> perhaps when it update interests). Therefore this lock is always
^
s
> acquired with F_GETLKW so as to serialise rather than fail on
> contention.
Doh, we're there, at last. Thanks for your work!
Regards,
--
Florent
Reply to: