Re: (fwd) Draft spec for new dpkg "triggers" feature
Frank Küster writes ("Re: (fwd) Draft spec for new dpkg "triggers" feature"):
> As far as I've been able to read it (I'm tired and stopped somewhere
> just before the WORKED EXAMPLE section), this sounds great for the TeX
> packages. We've got two use cases:
>
> - mktexlsr needs to be called whenever a file is installed in any
> subdirectory of /usr/share/texmf{,-tetex,-texlive}.
>
> Since this affects possibly hundreds of subdirectories, I guess this
> is a case for a non-file trigger?
Err, no, it seems like exactly a case for a file trigger.
> - update-updmap and subsequently updmap must be called whenever a file
> changes in /etc/texmf/updmap.d. Classical case for a file trigger, if
> I understood correcty that "file" can be a directory, too.
Surely this is not possible, because the system administrator (or some
other automatic process) might change files in /etc by hand.
> However, in this case an additional feature which I didn't find would
> be great: In case the triggered action fails and the package that was
> triggered is put into failed-config state, it would be very good to
> somehow be able to know: "Which package(s) activated the trigger?".
> In fact, when updmap failed, it was sometimes due to user
> misconfiguration - then it's okay that only the basic TeX package
> which provides updmap is known. However, an other possible reason is
> a buggy package, and in this case it would be nice to easily see which
> one triggered the updmap call. It's only a question of convenience,
> though: If we manage to get the bug reporter's
> /var/lib/texmf/updmap.log, we'll usually know.
Surely you can see which package is buggy by which package owns the
buggy data file in /etc/texmf/updmap.d ?
Keeping additional data with trigger activations, and passing it to
the postinst, would be tedious and cumbersome (as I wrote in response
to Bernhard Link).
Additionally, in your case it wouldn't give you the right information:
what you need to know is why package is responsible for the buggy
file, not which package(s) activated the trigger(s).
For example, suppose this happens:
* broken tex addon is unpacked
* new tetex is unpacked
* new tetex is configured
then during the tetex postinst run _no_ triggers are recorded has
having been activated.
The special `triggers' invocation of the postinst, and the list of
triggers, are for optimising away redundant processing and should not
be used for other purposes (such as attempting to guess which other
package to complain about).
> There's one more question here: both mktexlsr and updmap are provided by
> tetex-bin and by texlive-base-bin currently, and packages which would
> trigger this would (directly or often indirectly) depend on
> tetex-bin | texlive-base-bin [...]
It's not clear to me why this dependency is needed. It's not
necessary for the triggers mechanism to function as expected: if
tetex-bin (or whatever) is installed then it gets told about triggers,
and if it isn't then that's fine and the other packages don't need to
worry.
Perhaps the dependency is needed for some other reason.
> update-updmap, on the other hand, is in tex-common on which all of them
> depend. I've not though through whether the specification caters for
> this - it should.
I'm not sure I understand what you think the potential problem might
be.
Ian.
Reply to: