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

[Frank Küster]

Sebastian Rahtz <sebastian.rahtz at computing-services.oxford.ac.uk> wrote:

> Moving files from texmf-dist to a straight texmf could be done in the Debian
> build process, so its not that big a deal. The main argument against it
> is that after going through all the work of arguing about it, agreeing to do
> with teTeX too, it would be retrograde of Debian to undo it all again.

Is there any public archive of this arguing?

> Although we don't want the TeX tail to wag the Debian dog,
> we don't want the Debian tail wagging the TeX dog either.
> I strongly support leaving well alone in the TL setup.

I do not understand why such a divergence would imply any "wagging". My
point of view is - it might be wrong:

- We cannot take teTeX or tex-live as-is when creating a Debian package,
  some adaptations are necessary in any case. This is needed because we
  have to integrate into the system, and have some additional
  constraints, as well as that some problems don't exist here.

- On the other hand, it does not make sense that teTeX and tex-live
  adapt to the needs of Debian (or rpm-based distributions). In the
  first place, it should be possible to install and use them as easily
  as possible if you install them locally without any package management
  system, and on a variety of platforms.

- The adaptations needed specifically for Debian include things we add,
  things we do different, and things we drop or disable. A user who
  switches from a manually installed teTeX or tex-live to the Debian
  package will have to read the docs and possibly change habits *anyway*
  as soon as he wants to do any local adaptations.

  Therefore I do not see why we should not drop the distinction between
  TEXMFMAIN and TEMFDIST, too, when it doesn't make sense or a
  difference in *our* context.

I must say, however, that these considerations were all made without
considering the possibility of tex-live Debian packages, and generally
without considering tex-live at all. I was going along the following
reasoning: 

Instructions that could be found in any CTAN package should also apply
to Debian, whereas things that would not (or should not) be written in a
general README can as well differ.

This means, or course, that we strictly¹ adhere to the TDS, but that we
have a slightly different setup with respect to font maps - updmap.cfg
is not a real configuration file, it is generated from real
configuration files.

There is of course a grey area here. And maybe we must consider more the
influence of tex-live, both on Debian when it is going to be packaged,
and on the tex-scene in general - when more and more instructions say
something like "1. usual systems; 2. miktex" we should behave as a
"usual system" as much as possible.

Still, in the specific case of separating files into TEXMFDIST and
TEXMFMAIN, I don't see what problems would be caused by this. I only see
that we would have an additional directory in /usr/share (which doesn't
matter a lot) and would get some confusion: bug reports because files
added by the user or by "I have no explanation" in one of them shadow
package-provided files in the other. And maintainers of other packages
would have to be convinced to put their files in the correct location.

By the way, I doubt that we could use the straightforward naming scheme
for the directories, /usr/share/texmf for TEXMFMAIN and
/usr/share/texmf-dist for TEXMFDIST. Instead, TEXMFDIST would probably
have to stay /usr/share/texmf, because this is the place where all the
other packages install their TeX input files, and it would mean a
tremendous amount of work for us teTeX maintainers to file bug reports
on all of them and help the package's maintainers understand and perform
the change. I have better things to do than that, or rather I would like
to see more convincing reasoning for this change than just "upstream did
it". 

Regards, Frank


¹well, not even that. At least I am considering to implement a
backwards-compatibility hack to enable a smoother transition to the new
location of font encodings. As is, Debian packages that provide fonts
for TeX will either work with tetex-2.0.2, or with tetex-3.0, but not
both. Since we want to enable people to easily backport tetex-3.0 to
sarge, we probably need such a hack.
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer