Bug#400742: Bug#431671: Bug#400742: Bug#431671: piuparts test: fails to install: line 43: update-updmap: command not found
Rene Engelhard <rene@debian.org> wrote:
>> Reason: if there were TeX files in any previous version of the package
>> (up to the previous Debian release), then mktexlsr *has* to be run.
>
> Why weren't they in their own package then?
Huh? I don't know. I'm not the maintainer of texpower.
> Then if the package goes away you already have the postrm run mktexlsr
> because it's there in the old package and gets run when you remove it.
Hah! So you would want mktexlsr to be run on 'postrm upgrade' for every
package that ships .tex files and runs dh_installtex, right?
I'm not opposed to that, because this is clean. But do you realize that
if go that route, when a package containing .tex files is upgraded to a
version that also contains .tex files, then mktexlsr would be run *twice
in a row*? Once by "old-postrm upgrade" and once by
"new-postinst configure".
I can very well imagine the gazillion bug reports we would get if we did
that.
Reminder:
* Why does mktexlsr need to be run on upgrade?
Because the list of .tex file can change (new files, removals,
renamings).
* Why does mktexlsr need to be run by "postinst configure"?
Because when you go from the removed state to the installed state,
the .tex files added by the installation have to be registered.
Since "new-postinst configure" is automatically run on upgrades anyway,
we thought it not useful to *additionally* run it on "old-postrm upgrade",
but if that's what you want, we can enable that and let you deal with
the bug reports. :-P
If I follow your reasoning, you're embarrassed seeing mktexlsr being run
on "postinst configure" for a package that doesn't ship tex files.
Right. But at the same time, you would like that the previous version of
the package runs mktexlsr as "old-postrm upgrade" because "you know, the
next version might not ship the exact same list of .tex files". Since
we don't have a time machine, there is no way to know when writing
old-postrm that the next version will have .tex files (in which case,
running mktexlsr in "old-postrm upgrade" is useless, since it will be
run by "new-postinst configure" anyway). Therefore, by your reasoning,
we would have to *always* run mktexlsr in "old-postrm upgrade". Since,
with your proposal of looking whether the new version contains .tex
files, "postinst configure" would also cause a mktexlsr run whenever the
new version contains .tex files, you're proposing a system where
mktexlsr is run twice in a row in most cases. Doesn't look like an
improvement to the current system to me.
> I'd have split out the tex files (let alone because the dependencies on
> TeX stuff) and if you app really needs them make the app depend on
> *them*, not ship them in the normal packages.
Making a new binary package only in order to avoid a dependency on
tex-common in the "main package" is ridiculous. tex-common is quite
small.
> This is like comparable to programs/libs, where the (public) libs built from a
> programs' source package should also not be in package foo but in
> libfooX.
Gni? The reason we need libfooX is for other packages to depend on it,
and only on it. But programs that are the only users of their libraries
don't need to create libfooX binary packages.
> dh_installmenu does not add update-menus to everything because one
> package produced has a menu file and is therefore called. It just adds
> the needed stuff to the needed packages.
So?
> In contrast to that, dh_installtex when ran without -p adds its snippet
> to *every* binary package, may it have tex stuff in it or not.
And rightly so, because if the maintainer runs dh_installtex for a
package, he should have a reason to do so. For instance, because the
previous version had .tex files.
> Anyway, I just worked around it by using -p and will keep it mind.
It is not a workaround. It is simply "using the tool where it is
needed".
> Do whatever you think, but you are behaving completely different than
> many "normal" dh_*'s.
dh_installtex is doing more complex stuff than many dh_*'s. It is normal
that it is not a clone of all of them.
--
Florent
Reply to: