Re: [TeX Policy] On which tl package to depend to get mktexlsr, fmtutil and friends?
Hi,
Frank Küster <frank@debian.org> wrote:
> I've noticed frequently that packages start depending on
> texlive-base-bin and texlive-latex-base. I first thought that this is
> superfluous, because what they really want is a "latex" executable.
[...]
> However, many packages also call mktexlsr, fmtutil-sys, or updmap-sys.
> Should we require them to depend on tl-base-bin for this purpose, or
> should we code in the Policy that any package which provides a *tex
> executable will also provide the infrastructure functionality?
I'm not sure what you are trying to achieve:
- reduce two dependencies to one
- or avoid unnecessary installations of texlive-base-bin, which is
pulled by such dependencies.
But I fail to see how you could easily ensure that "any package which
provides a *tex executable will also provide the infrastructure
functionality".
The reason is, there are several packages providing a *tex executable,
and you cannot expect each of them to provide e.g. /usr/bin/updmap-sys
(that would cause a file conflict). I think you mean that each of these
packages depends on a package (currently texlive-base-bin) that contains
these executables, "so it's OK". IMHO, this reasoning is not very safe,
because if A depends on B, it is possible that A is configured and not B
(this a fact I really don't like, but as Ian explained, this is
necessary so that when we upgrade packages such libc6, we don't have to
deconfigure virtually all other packages). OTOH, I think that dpkg is
cautious to check that all dependencies of $package are configured when
you run "dpkg --configure $package".
So, if A depends on B and B provides updmap-sys & Co, the safe thing to
do for package C calling updmap-sys in its maintainer scripts is to
depend on B, even if it already depends on A. Which means, if C also
relies on A, it has to depend on both A and B, even though A depends on
B.
This ensures that B is configured at the time C is configured, so
updmap-sys should be working at that point.
As for the real packages, the correspondences are the following:
A -> texlive-latex-base
B -> texlive-base-bin
C -> any package using latex and updmap in its maint scripts
(I notice that texlive-latex-base does *not* depend on texlive-base-bin
even though it uses updmap-sys in its postinst; this is probably OK
because with the dh_installtex snippets, updmap-sys is only run if
present; this was done so that packages like lmodern don't have to
depend on TeX packages other than tex-common).
> In the end, it might even make sense to have an arch-all package with
> all the infrastructure scripts?
Well, what's the big difference with tl-base-bin? Is it too big? Or is
it because it's arch:any?..
> And finally, similar considerations apply to
> texlive-latex-{recommended,extra}: I would say that they will forever
> depend on a latex executable and hence on texlive-latex-base or whatever
> package that executable provides, so that depending on both is a bug?
Same thing: to ensure that latex is working when you are configured, the
safe thing to do IMHO is to depend on $package_providing_latex instead
of relying on a "transitive dependency" that leads to
$package_providing_latex.
Regards,
--
Florent
Reply to: