[tldistro] Experimental mapping of texlive packages to rpm packages

[Norbert Preining]

Hi Paulo,

On Mi, 02 Nov 2011, pcpa at mandriva.com.br wrote:
> > THis is what I am currently doing in Debian (in preparation).
> 
>   Do you have some prototype, or more specifically, what I have interest
> is in, how do you manage the config files updates and ls-R.

That will not change and is more or less the same since 2005 (!!!)
when I packaged the first version of TL for Debian. ANd actually,
if you are serious about packaging, there is not many other ways.

Let us 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 knoe which formats/font maps/hypehn patterns
  there are, and create snippets for these configuration file, 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 confiurations 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 are now 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 ;-)

> in the same "transaction", it runs mktexlsr only once.

Good idea, but not sooo important, because after the first run
normally all the files are in the file system cache of the kernel,
and running mktexlsr once more is fast.

> installing files in a "config.d" directory, and regenerating
> the files somewhat like the same way install-tl does, just that
> in that case, not using the texlive perl modules, e.g.:

Sounds like the right approach.

> $ cat /usr/share/tlpkg/Mandriva/fmtutil.cnf.d/aleph
> aleph aleph \- \*aleph.ini
> lamed aleph language.dat \*lambda.ini
> 
> $ cat /usr/share/tlpkg/Mandriva/updmap.cfg.d/adfsymbols
> Map ArrowsADF.map
> Map BulletsADF.map
> 
> $ cat /usr/share/tlpkg/Mandriva/language.dat.d/dehyph-exptl
> % from dehyph-exptl:
> german-x-2011-07-01 dehypht-x-2011-07-01.tex
> =german-x-latest
> ngerman-x-2011-07-01 dehyphn-x-2011-07-01.tex
> =ngerman-x-latest

Yes, this is the way to go. 

You probably have the advantage that you don't have to care for
sysadm changes, as you don't allow them ;-))) Sometimes I wish
I am not on Debian, which is soo conservative in keeping changes
of sysadmins ;-))))

>   Another question, how do you plan to manage updates? I did
> initial work not using the "revision" metadata in the tlpobj
> files, but probably the best approach to automate some tool
> do know when there are updates. And my current plan before
> actually starting using the new approach is to write some
> script to handle it, so that, from time to time can check
> what has been updated.

I will have debina packages of the form
	texlive-<collection-name> 
	version: 2011.YYYY.MM.DD-d
where YYYY.MM.DD is the tlnet of that day, and -d is the Debian version.

THis way I can update whenever I want. I will not do it on a daily
bases.

Furthermore, in Debian we only have 5 source packages, and for every
collection one binary package (all source packages build several binary
packages).

If I could have one TL package -> one Debian package, that would be *easy*
and *nice*, but our ftpmaster (the guard of the holy grail) will not
allow to enter 2000+ packages ;-)

Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining            preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan                                 TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
BILBSTER
A pimple so hideous and enormous that you have to cover it with
sticking plaster and pretend you've cut yourself shaving.
			--- Douglas Adams, The Meaning of Liff