[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [TeX Policy] On which tl package to depend to get mktexlsr, fmtutil and friends?



Florent Rougon <f.rougon@free.fr> wrote:

> 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.

I mean the first, and not only because of the number of dependencies.
Currently, we have one package (tl-base-bin) which provides both pdftex,
dvips and xdvi on the one hand, and the infrastructure scripts (updmap,
fmtutil, mktexlsr,...) on the other.  If people depend on tl-base-bin
because they call updmap (or so), we have less freedom should we want to
separate these two aspects in two packages in the future.

> 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). 

No, but they currently all depend on tl-base-bin, and would continue to
depend on the "infrastructure package" if such a separation would
happen, and if we now decide that we give such a guarantee.

> 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".

That's a good point.  So we should instead write into policy which
package will provide the infrastructure scripts.

>> 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?..

It was just an idea; currently I don't see a real reason.

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)



Reply to: