[tex-live] Re: Debian-TeXlive Proposal II

Frank Küster frank at debian.org
Wed Jan 26 09:42:53 CET 2005

Norbert Preining <preining at logic.at> schrieb:

> Dear Frank, dear Karl, dear all!
> On Die, 25 Jan 2005, Frank Küster wrote:
>> Why not texlive- or tex-live-? All package management systems I know of
> Ok, Karl also suggested texlive- prefix. Good with me.
>> > 	lib-XXX		->	tl-lib-XXX	(??)
>> Especially for libkpathsea it is perhaps better to keep it static. Olaf
> All the binaries in TeXlive use a static libkpathsea, but also static
> linked in libjpeg, libpng etc (pdftex). I guess these `should' be made
> dynamic depending on the respective debian libraries.

Yes, of course - but that also means that tex-live need not create any
library packages.

>> > - What is still unclear for me is how to cope with all the packages: If we
>> >   do it the way proposed below, we have:
>> > 	bin-packages:	 80
>> How do you get so many binary packages? tetex-bin contains 139
>> executable files, but only 61 of them are actually binaries - the rest
> Yes yes yes. The -bin comes from the
> 	bin-XXXXX.tpm
> stuff. `binary' here means some executable, not necessarily a real
> binary.

And I think you should group them together. There's not any gain in
having separate packages for pdfetex and mf - you need mf anyway if you
use bitmap fonts. There's only little gain (possibly less security
downloads on a site) if you separate pdfetex, dvips and xdvi. And I
cannot see any sense in having a separate package just for symlinks
(latex) or shell scripts. 

It might make sense to separate them according to dependencies -
texlive-bin-basic, texlive-bin-perl, texlive-bin-x11. But in fact perl
will be installed on every Debian system, and it is easy to patch perl
scripts so that they give a decent, understandable error message if some
module is missing[1]. Same goes for X11: There is a sense in being able
to install teTeX on a server that has no Xlibs installed, e.g. for
automatic document processing. But such a server would probably be
rather "conservative" and use teTeX, not tex-live.

Summary: I advice to create only one or a small number of binary

> So my suggestion is to actually DO some additional `aggregations' (maybe
> only a few) but otherwise keep the collections.

You're probably right - it's one of the good features of tex-live that
you can have a comprehensive installation, but also select in detail
what you want. We should be prepared for a medium sized flamewar on
-devel, though.

One thing that doesn't seem to fit for me, however, is the hyphen
stuff. Have you considered how you would handle language.dat? You have
to keep in mind that:

- The packages containing additional patterns must be able to modify

- Users might install some patterns by hand. For example non-free
  patterns, but after a relicensing it could be that they are added to

- Users must be able to configure which patterns to use for languages
  with several of them (russian, ukranian, norwegian).

- Users must be able to use their own, modified and renamed versions of
  patterns for their language

And all these things must work together on one system. A technical
solution that works would be to use a scheme like update-updmap and
update-fmtutil in tetex-bin. But, similar to texmf.cnf, you have the
problem that language.dat is a file that is *often* mentioned on the net
in some tutorials and README's (as opposed to fmtutil.cnf and
updmap.cnf, which are not so frequently mentioned). Either you put it
into /var, but will have a hard time stopping people from editing it. Or
you put it into /etc and have a double-layer configuration like we have
with texmf.cnf - I would not advice to do this again (see also bug

Regards, Frank 

[1] texdoctk, texfind, and some more depend on perl-tk, but tetex-bin
only Recommends it, not Depends. If you run them without perl-tk
installed, a message will pop up in Debian, telling you to install it.
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

More information about the tex-live mailing list