Re: (fwd) Draft spec for new dpkg "triggers" feature
Ian Jackson <ian@davenant.greenend.org.uk> wrote:
> 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.
Ah, the wording was unclear to me. So, in
,----
| File triggers [...] are activated when the specified filesystem
| object, or any object under the specified subdirectory, is created,
| updated or deleted by dpkg
`----
"under" does not only cover files directly in a subdirectory, but
anything in the hierarchy below it. Maybe this should be worded more
clearly.
>> - 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.
I'm not sure I understand you. I understood, however, that I was not
writing as exact as I should have:
s/file changes/file is changed by dpkg/.
> Surely you can see which package is buggy by which package owns the
> buggy data file in /etc/texmf/updmap.d ?
Well, if I am able to look at all files in the bug reporter's updmap.d,
either becaues he sends them or because I can reproduce the bug, then I
can. But users who do not manage to send the updmap.log file or the
tempfile, even if the error message from postinst tells them so, are
often not willing, responsive and whatever enough to send the right
files from some directory in /etc ("I have cleaned updmap.d and
reinstalled foo, but it still doesn't work" "What do you mean with
'doesn't work'?",...).
If dpkg just says "the failed trigger was activated by foo, bar, baz",
then I can go ahead and try to reproduce the bug by installing foo, bar
and baz in sid, testing or whatever. It would make debugging much
easier. Without the information, I get a bug report for the triggered
package (say, texlive-base-bin), which includes the "dpkg -l" output for
packages on which texlive-base-bin depends. But it does not report
about installed packages that depend *on* texlive-base-bin.
In this case it's really hard to give more informative output, because
updmap is very verbose on stderr. We redirect that to the tempfile, but
if we just 'cat' the tempfile in case of an error, the user gets a
couple of screens and again it's likely that a bug report will include
lots of useless information, but the important stuff is cut away...
> 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).
Why do you think this needs to be sent to the postinst? All that's
required is that dpkg remembers who activated which trigger (which might
be tedious, that's yours to decide). Then when the trigger fails, dpkg
will set the triggered package to failed-config state, and at the same
time it will give an error message, correct? This is the place where I
suggest that it looks up which package(s) activated that particular
trigger, and tells me about them.
> 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.
That's the same situation as without triggers, no worse and no better.
So it doesn't matter here. What matters is if a TeX is already
installed and configured, and the broken tex addon is installed later,
together with a couple of non-broken packages.
> 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).
Yes, of course. This is why I'd prefer dpkg to tell me.
>> 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.
Yes, it's needed anyway, and it seems I misread some part of the
proposal (some part I can no longer find now...)
>> 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.
I thought that I had read somewhere that dpkg would bail out if package
foo wants to activate a trigger in which no package is interested. I
know now that this is wrong.
Regards, Frank
--
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Reply to: