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

[Frank Küster]

Norbert Preining <preining at logic.at> schrieb:

> Proposal for a Debian packaging system for TeXlive
> ==================================================
> (last update: 2004-01-25)

Looks quite good, all in all.

> All debian package names are prefixed with tl-

Why not texlive- or tex-live-? All package management systems I know of
do very well with long package names; the only problem is "dpkg -l" or
"dlocate -l". And it is more descriptive and contains the word TeX.

Alternatively, if you prefer the short prefix, I suggest that you do use
a longer name for a couple of meta packages that do nothing but pull in
the actual packages, like "texlive-minimal" and "texlive-complete".

> The tpm in texmf/tpm/ (collection-*, bin-*, lib-*, hyphen-*, scheme-*) 
> are mapped to debian packages.
>
> Mapping:
> 	bin-XXX		->	tl-XXX-bin 	(standard debian notation)
> 	collection-XXX	->	tl-XXX
> 	lib-XXX		->	tl-lib-XXX	(??)
> 				can be ignored as the binaries are currently
> 				more or less static
> 				for proper debian we have to build it wrt
> 				the installed debian libs

Especially for libkpathsea it is perhaps better to keep it static. Olaf
Weber said that people who previously used it as a dynamic library
should continue to do so, but he discouraged to switch to dynamic
linking before its successor, libkpse, had its birth. As teTeX
maintainer, I didn't need to make a decision, because when I joined it
was already a dynamic shared library. However, I wouldn't advice you to
do the same with tex-live, and if you decide to link it statically to
libkpathsea, this decision can very well be defended in the light of
Debian Policy. In this case you wouldn't need any libXXX package at
all. 

> 	hyphen-XXX	->	tl-hyphen-XXX
> 	scheme-XXX	->	tl-scheme-XXX

I'm not familiar to the tex-live splitting scheme. But aren't these
hyphen packages really small bits with only one or a couple of input
files? Is it worth splitting them? And how are you going to handle
language.dat - it must probably be a configuration file, or generated
from configuration files.

> TPM-Requires between these packages are mapped to Debian Dependencies.
>
> All other files obtained from a TPM-Require are included in the 
> debian package.

This does not lead to one file being in two packages?

> Thus we have:
> binaries:
> 	tl-afm2pl-bin tl-aleph-bin tl-amstex-bin tl-bibtex-bin ...
> collection:
> 	tl-basic tl-bibtexextra tl-binaries tl-chemistry tl-context ...
> schemes:
> 	tl-scheme-basic tl-scheme-context tl-scheme-full ...
>
> As an example, tl-chemistry Debian-depends on
> (binaries)
> 	(no)

As a Debian package, it must of course depend on either some tl-XXX-bin,
or on tl-XXX-bin | tetex-bin. I think it would be desirable to be able
to use TeX input files from tex-live with tetex-bin, but this shouldn't
be the primary goal.

> Location of the stuff:
> ======================
> binaries:
> 	/usr/bin/
> texmf trees
> 	we have several texmf trees:
> 	TEXMFMAIN = /usr/share/texmf
> 	TEXMFDIST = /usr/share/texlive/texmf-dist
> 	plus the texmf trees specified in the Debian-TeX policy
> 	(VARTEXMF, SITETEXMF, TEXMFLOCAL, HOMETEXMF, TEXMFOLDLOCAL)

Since I didn't see any sense in TEXMFDIST for a Debian package[1], I
was inclined not to use it, but keep all files in TEXMFMAIN (plus the
generated ones in VARTEXMF). I think we should coordinate on this. 

> config files
> 	/etc/texmf with links from /usr/share/texmf/web2c/... to /etc/texmf

And from TEXMFDIST, like $TEXMFDIST/latex/config, or hyperref.cfg

> Implementation of foreign arch/os binary packages:
> ==================================================
> For binaries with the only purpose of being served (via nfs/smb/etc) 
> of other os/arch combinations architecture-independent debian packages
> are created:
> 	tl-<progname>-arch-os	(arch=all)
> 	tl-binaries-arch-os	(arch=all)
> e.g.
> 	tl-aleph-i386-solaris
> 	tl-binaries-i386-win32
> These packages contain the binaries (what about the included man pages?)

"Normal" Debian packages are required to ship a man page for every
binary in the package, not in a accompanying -doc package. I think this
would make sense for the served packages, too.

> Questions:
> - Is it possible to circumvent the double installation of binaries for the
>   normal system (into /usr/bin) and into /src/texlive/arch-linux?
>   Idea: Put *all* binaries for one arch into /srv and mount them
>   via --bind to /usr/lib/texlive/bin/, and put symlinks from /usr/bin to
>   /usr/lib/texlive/bin. Is this an option?

I doubt it. mount --bind might not be supported on all filesystems or
kernels, and there is no way to express "Depends: 'not $whatever on
/srv'". Technically, you could just create symlinks to the binaries in
/srv/texlive/$arch-linux, but that would violate the FHS. And there is
usually a reason to adhere to it, except that it's required by Debian
Policy. 

One option would be to have two srv-only-packages for each arch-os
combination: 

tl-binaries-<arch>-<os>, Depends: tl-binaries-<arch>-<os>-real | tl-binaries

with tl-binaries being the respective package that puts files into
/usr/bin, while the -real packages puts its files into
/srv/<arch>-<os>. tl-binaries-<arch>-<os> does nothing if it finds that
tl-binaries-<arch>-<os>-real is installed, but if it finds that
tl-binaries is installed, it creates symlinks.

But again, cross-filesystem symlinks are a problem AFAIK, and so this
might not be feasible, too; it's not satisfying from an "aesthetical"
point of view, anyway.

Well, why bother at all about duplicate files? If you're going to set up
a server that will host application data for your department, you should
really by a harddisk big enough that a couple of double binaries don't
matter. A "couple" of files in two texmf trees (one in /usr/share/texmf,
one in /srv/texlive) may in fact matter, but this is also hard to
avoid. Does the server need a TeX system at all? If it does, buy a big
enough disk.

> - 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
is architecture-independent scripts and symlinks. Why not just install
all the main programs (pdfetex, tex, mf, kpse*, bibtex, makeindex,
dvipdfm, dvips, xdvi, and the stuff needed for pk-font creation) in one
tl-bin-basic, and put all the rest into one tl-bin-...?

> 	collection:	 75

This looks like quite tiny bits. Are these collections grouped
hierarchically in the current texlive installer? Maybe you can add some
of the headings higher in hierarchy as packages that depend on their
lower entries?

Personally, I would prefer to split TEXmF into something like 10 or 25
packages.  But I must say that I never made any real effort to actually
look into the TEXMF tree of tetex, let alone CTAN, and decide which
could be grouped. For sure only splitting into -base and -extra, as we
currently do for teTeX, is suboptimal; for tex-live the two would be
horribly big. If there is no better splitting scheme than your
collections, well, maybe then it's better to have 75 packages than to
have 20 badly split ones.

> 	scheme:		  8
> 	hyphen:		 30

Again: Does it make sense to split this? And have you thought about how
to combine the installed ones into language.dat?

Regards, Frank

[1] IIRC, the purpose of TEXMFDIST ist to enable the user to just
replace the directory completely when a new tarball is released; you
can't do this with a Debian package, but there's also no need for it.
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer