[tex-live] Re: Debian-TeXlive Proposal II
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
>> > - 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
> stuff. `binary' here means some executable, not necessarily a real
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. 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
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
 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.
Inst. f. Biochemie der Univ. Zürich
More information about the tex-live