Copyright (C) 2011, 2012 Peter Breitenlohner <tex-live@tug.org>
You may freely use, modify and/or distribute this file.

	Building TeX Live (TL) for a distro
	===================================

Although they use the same code base, building for a TL binary distribution
as shipped by the user groups may be quite different from a `distro' build
for, e.g., some kind of Linux distribution, a *Bsd or Mac OS X port, or
similar.

While a TL binary distribution uses shared libraries (libc, libm, X11
libraries, and libfontconfig) only when absolutely necessary, a distro might
use as many shared libraries as possible, including the TL specific
libkpathsea and libptexenc.

In addition the installation paths will, in general, be quite different.

1. Configuring for a distro
===========================
Here we give some hints how to configure TL for a distro (see README.config
for a fairly complete description of all configure options).

1.1. General setup
------------------
You must use
  --disable-native-texlive-build
otherwise many options described below are rejected, and should use, e.g.,
  --with-banner-add=/SomeDistro
to identify your distro.

You may specify
  --enable-shared
to build the TL specific kpathsea and ptexenc libraries as shared libraries
and may add
  --disable-static
to not build the static libraries.

You should use
  --with-system-LIB
(for LIB=zlib, libpng, zziplib, etc.) to use installed libraries (including
kpathsea and ptexenc for the TL specific libraries, e.g., when rebuilding
individual programs) and you may have to add
  --with-LIB-includes=DIR
and/or
  --with-LIB-libdir=DIR
to locate the installed headers and libraries.

1.2. Installation paths
-----------------------
If you specify, e.g.,
  --prefix=/usr
binaries will be installed under
  /usr/bin
libraries under
  /usr/lib
header files under
  /usr/include
info pages under
  /usr/share/info
mnual pages under
  /usr/share/man
and the principal TEXMF trees under
  /usr/share/texmf{,-dist}

Moreover you can use
  --exec-prefix=DIR
and
  --{bin,lib,include,info,man,dataroot}dir=DIR
to modify these default choices.  Depending on your distro you might want to
specify
  --libdir=/usr/lib64
or similar on 64bit bi-arch (Linux) systems.

The top-level configure script displays the actual installation paths.

For a `staged install' (see Automake manual 12.4), e.g.,
  mkdir /tmp/staging && make DESTDIR=/tmp/staging install-strip
all installation paths are prefixed by the value of DESTDIR.


2. Packaging for a distro
=========================
From Norbert Preining <preining@logic.at>, 2011-11-04, email to tldistro.

This describes Debian packaging, but the basic ideas are the same for all
distros.

Let us discuss the few important things in turn:
- ls-R files
- updmap-sys/updmap.cfg
- fmtutil-sys/fmtutil.cnf
- fmtutil-sys/language.dat/def/lua.def

All these files depend on the actually installed packages. So you
should never never use the pre-shipped files (updmap.cfg, ...), because
they refer to *all* fonts in a full installation.

But if you want to allow for smooth upgrades etc, and partial installs,
you cannot do that.

So the Debian way for these files is:
- at package build time we know which formats/font maps/hyphen patterns
  there are, and create snippets for these configuration files, and
  at install time put them into /etc/texmf/updmap.d, fmtutil.d, hyphen.d
- after the package has been installed the configuration routine does:
  . assemble the pieces together to updmap.cfg/fmtutil.cnf/language.*
  . run the necessary commands (also determined at package *build* time,
    that is updmap-sys, fmtutil --whatever, etc)
Furthermore, in Debian there is another requirement, namely that
if a sysadm changes configuration files (hereafter called conffiles)
in /etc, and the package is only removed (that is, the conffiles are
*NOT* deleted) but NOT purged (purged = also conffiles removed),
then a later installation of the package has to honor the changes the
sysadm made.

That means, there will remain snippets in /etc/updmap.d (for example)
if a font package has been removed, but not purged. These snippets
should of course NOT be merged into the main config file. So we ship
in addition a file /var/lib/texmf/fmt.d/.... and check at assemble
time if this file is present. If it is present, then the snippet
is used, if not, then it is NOT used.
(BTW, this also happens during partial upgrades, so if you are serious
about packaging, think about that, too).

Well, that is the story at least till 2007. In later version of the Debian
packages we now use something called "triggers", where a central package
(in our case "tex-common") shows interest in a certain directory, namely
the directories /etc/texmf/fmtutil.d etc (all of them), and if a file
is dropped there or changed there, only some specific code in tex-common
is executed. This way we can reduce the calls to mktexlsr and updmap-sys
a *LOT* (think about installing every collection of TeX Live, and run
mktexlsr, fmtutil-sys --all, updmap-sys after *EACH* collection, versus
running it only once or twice!). But this is Debian specific, and probably
no other distribution has a similar system (although very useful).

Puuuuh, long email. BTW, there are loads of documents in the tex-common
package of Debian: http://packages.debian.org/sid/tex-common, especially
the main documents Debian-TeX-Policy and TeX-on-Debian. Although a bit
outdated, they describe the reality quite closely. Get the .deb and
unpack it with ar ;-)



Happy building.  Please use the tldistro list for questions or
discussion: http://lists.tug.org/tldistro.
