[tex-live] Packaging TeX for (Linux) distributions (was: teTeX: no next release)
frank at kuesterei.ch
Tue May 30 14:49:01 CEST 2006
I'm not sure whether the texlive list is the right place for this
discussion, but I also don't know a better place...
"Michael A. Peters" <mpeters at mac.com> wrote:
> I started the project before I knew teTeX would be abandoned.
> The intention was provide a way for addon packages and updates to be
> installed. As an RPM should never own any file in /usr/local (where RH
> puts TEXMFLOCAL) and I really like to have _everything_ on my system
> under the management of RPM, creating a new TEXMF tree for updates was
> the only option that would guarantee no file conflicts with present or
> future packages.
According to Debian Policy, packages may not own any file in /usr/local,
but they may (and should) create empty subdirectories in /usr/local in
their installation scripts (and I don't think this violates the FHS).
Thus, it is easy to prepare support for a seamlessly working
Actually, from our point of view it's easier to make installations in
TEXMFLOCAL work, than additional rpm's. Instead of having
fmtutil.cnf, updmap.cfg and texmf.cnf, and now even language.dat as
configuration files, the packages now contain configuration directories,
and the actual configuration files are generated from the content of
these directories. Attempts to handle for example updmap.cfg with calls
of "updmap --enable" or "--disable" in the installation/removal scripts
didn't work, because this would overwrite local changes.
But I think we've now found a way that makes it easy to create
additional deb's for fonts and similar things.
> Correct me if I'm wrong, but (I guess like teTeX) it looks like TeX Live
> does not use "pristine" upstream sources, but rather creates zip
> archives from what is on CTAN. While I'm sure that RPM files could be
> created from the individual TeX Live zip archives, I think it is better
> to use "pristine" upstream when possible. That may actually help avoid
> situations where a license is mis-interpreted and a file is modified
> that the upstream author did not want modified.
I am not aware that TeXLive makes any changes to files on CTAN. They do
synchronize their development tree to CTAN on a regular basis. How this
development tree is finally released is a different question; on an
ordinary TeXLive CD, the files are somehow compressed (I think it's zip
on a per-tpm basis). But for the Debian packages of texlive, only a
couple of huge orig.tar.gz files is created which are then compiled, if
necessary, and split into appropriate installation packages (debs).
> In fact with tetexrpm, even before the recent cstex issue, I had written
> policy in the guidelines that patches would not be done at all because I
> don't want tetexrpm to be a fork.
That's a reasonable approach. For the Debian packages, we have applied
patches on rare occasions, but that is a decision we made as
distributors, with our release timeline as a reason.
> With respect to teTeX being "dead" now - sitting on my hard drive right
> now is a set of "teTeX like" RPMs built from TeX Live 2005. I could not
> use pristine source because of bootstrap issues (you need TeX installed
> to unpack the dtx files).
> I'm not quite ready to make them public, but I think it is the right
> solution for people (like me) who like the teTeX packaging.
It would be interesting to look at this.
> The "real work" of maintaining the texmf tree and the source tree IMHO
> is not needed. Let TeX Live do that, and use the TeX Live yearly
> snapshot as the base for the packaging of something that is equivalent
> to current RPM packaging of teTeX. That way effort is not wasted.
> Development for free UNIX LaTeX can continue in TeX Live, and when TeX
> Live makes a release, the "teTeX like" packaging can then be created
> rather easily from it. No need to maintain a separate source and TEXMF
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
More information about the tex-live