Re: Draft spec for new dpkg "triggers" feature (v2, repost)
Florent Rougon <f.rougon@free.fr> wrote:
> 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.
I don't think so. Usually, the lines "quoted" above are caused by
apt(itude) invoking dpkg like this:
dpkg --configure lmodern other-font-package texlive-base-bin bar baz wrmft-foo
And then the intended effect will be achieved.
>> 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)
The reason can be extended by the scenario that I is installed after the
Ts (and no T depends on I, maybe Suggests or Enhances).
A package I may be installed and configured after and independently
of packages T which would have activated one of its triggers, had it
been installed earlier. Therefore, I's postinst must do any work
needed for trigger processing even when called with "configure".
Regards, Frank
--
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Reply to: