[tex-live] Packaging TeXlive as Debian packages

[Gavin McCullagh]

Hi Norbert, Sebastian, all

On Wed, 05 Jan 2005, Norbert Preining wrote:

> I want to hear your opinion on the packaging concept of TeXlive for
> Debian:

As a huge Debian/APT fan and a maintainer of a TeX Live network system I
cannot stress how much I dream of this project coming to fruition.  Please,
please, please do it.  I am not a Debian packaging expert but I really
would love to see this done and would be interested to put some time into
helping, even if only as a tester.  

A few points that I would like to raise.

0. Once --- in a dream --- I considered doing this unofficially myself.
However, I simply wouldn't have had the time or expertise.  My strategy
would have been to start off with a small number of very large packages
(tl-bin-i386, tl-fonts, ...) and to gradually fork them into smaller ones
where necessary or beneficial.  As has been said elsewhere the work
involved in having a Debian package for every atomic unit of texlive seems
enormous and impractical.

I doubt one could automate creation of updated Debian packages when the
existing tree gets updated.  However, it would be far more plausible to go
the other way, ie if everything was first done as a Debian package, the
traditional tree could be automatically updated from it.  Perhaps this
might add too much strain to general maintenance though.


1. It is very important (for me) to be able to install binaries for several
architectures.  We keep a central tree which many users on different OSes
use and the existing bin/<arch>/ structure is very convenient.  While I
know if I'm on i386 Debian will transparently pick the correct binaries,
there is much to be said for having packages:

	tl-bin-i386
	tl-bin-win32
	tl-bin-macosx, etc

possibly with a dummy tl-bin package which selects the correct one from the
above.  I'm unsure of the correct Debian location for foreign binaries
(might it be /opt?) but I can't imagine it hasn't been answered before in
Debian policy.


2. It is important in Debian packaging to use the correct locations (docs
in /usr/share/docs; binaries in /usr/bin; etc etc).  However, the way we do
things currently is to have the single texlive/ directory shared over samba
and nfs.  This would be messy if things are spread out properly as per
Debian rules.  

It may be argued that the APT system just doesn't suit this but this would
be very disappointing.  One solution would be a small package called
something like tl-tree which uses many symlinks to simulate the previous
tree.


3. There are several very cool packages in Debian which handle use of
non-distributable stuff (eg flash, java).  What they do is create a small
package which when it is being configured prompts for the path to the
3rd party package.  The user downloads this themselves.  The Debian package
config then puts things in the right place and integrates it properly (eg
symlinks into browser plugin dirs).

I would suggest the above method could be used for 3rd party fonts.  It
would prompt for the tarball or loose pfb/afm files which the user
provides.  Then it would rename them, place them correctly, create or
install the correct supporting files (eg Walter Schmidt's) and run texhash.
In that case 'apt-get install tl-font-support-adobe-baskerville' would be
the method to install Adobe Baskerville.


4. There was a question of what to do when two packages installed the same
files.  I believe the general strategy in Debian is to create a xxxx-common
package which is required by both and contains these "common" files (eg
mysql-server, mysql-client both require mysql-common).  I may have
misunderstood the question though.


I hope some of these points are helpful.  Good luck in this most worthwhile
endeavour.

Gavin