Dear all,
there are a lot of requests for a more clever splitting of tetex-base,
-bin, and -extra in the BTS. Now that we are early in the release cycle
of etch, and teTeX-3.0 is finally in unstable, I want to approach the
question of splitting.
This mail goes to all the bugs that refer to splitting, and (via Blind
Cc) to all submitters (and some other related parties who have in the
past expressed interest in the topic). Followups should go *only* to
the bugs in the To: field, this will reach me and the Co-maintainers.
Please restrict yourself to one of them if your answer only affects one
of the packages; tetex-extra is built from the same sources as base.
Submitters, if you are interested in further discussion, please
subscribe[1] to (one of ) the bugs in the To field (or the
debian-tetex-maint@lists.debian.org mailing list).
In the following, I will try to
1. summarize the requests we have received and their motivation
2. propose some guidelines for splitting
3. propose some possible splitting schemes.
4. timeline
Here we go:
1. Summary of the requests we have received and their motivation
===============================================================
(plus some comments in [])
regarding tetex-bin
a) #78926: If possible, it'd be nice if dvips were a seperate package, so that
users
of printfilters, e.g., don't need tetex-bin installed.
[is this really a realistic scenario? How many systems are there that
print dvi, but don't produce it?]
b) #100332: please move xdvi to its own package
Motivation: This would save lots of packages that build documentation
with TeX the indirect build-dependency on xlibs
[maybe not so grave any more since xlibs are modularized, but
generally a worthwile goal]
c) #223728, #223734: tetex-bin needn't depend on xlibs (and split of stuff
depending on perl-tk, and corresponding patch for tetex-base)
Additional motivation: allow (pdf)tex to be run on production
machines without X installed.
regarding tetex-base
d) #302035: PSNFSS is a required part of LaTeX
Motivation: tetex-base should contain everything that is part of core
LaTeX
e) #324868: Move Bluesky fonts to tetex-base
Motivation: tetex-base should be sufficient for basic document
processing, and today this means to be able to produce PDF files with
Type1 fonts (which Bluesky provides at least for english)
[Along these lines, we should consider to move often used LaTeX
packages to -base]
f) #32260, #35892: Split tetex-extra to minimize disk space requirements, and
allow bibtex (and other programs in -bin) to run sensibly with only
-base installed.
[this is an understandable wish for bibtex, but not necessarily
sensible for exotic engines like omega, aleph, ...]
g) #51869: Like before, but discusses the issue of splitting tetex-doc
off, or alternatively having smaller junks with the respective docs
included.
h) #278901: Like before, but focuses on the regular download size in
unstable, which could only be reduced by an artificial splitting of
the *source* package. This is a different topic, we are *not*
discussing this here.
i) #327480: Please separate the .pfb files of Type1 fonts and make them
available to X11
[partly resolved since CM fonts are available as TrueType for X11;
still valid for other fonts]
2. guidelines for splitting
========================
Etch will (if nothing very surprising happens) come with two alternative
TeX systems: teTeX and TeX-Live. TeX-Live is not only much bigger and
more comprehensive, it is also much more fine-grained. This will allow
users to install only the specific subset they need. Therefore, I think
we can refer people concerned with download size or disk space to using
TeX-live and simply not care about this problem; teTeX is then for
everyone who wants a standard collection of things without bothering
about disk space, or about selecting from a large list.
This effectively resolves bugs f, g, and h, except that we should
consider the aspect of splitting doc files.
I expect that teTeX will continue to be the standard package for
creating documentation when building a Debian package, and I think that
we should try to develop our splitting schemes mainly along the needs of
this application. End users will probably just install everything, or
switch to tex-live.
>From this, I find the following guidelines:
1. do not bloat indirect build-deps
2. provide a tetex-base that is sufficient for most generated tex-files
(by debiandoc-sgml, linuxdoc, texinfo, or similar approaches)
3. do not include unnecessary stuff in the basic packages needed for
most build-deps
3. Some possible splitting schemes
===============================
For each of tetex-base and tetex-bin, I see two possible splitting
schemes - one that would fulfill minimal requirements, the other
"better" but more difficult and more work.
3.1 tetex-bin
- To me it seems that splitting of dvips (a) will gain us hardly
anything, and most users will install it anyway; currently the same is
true for build-depending packages, although more might switch to
direct pdf generation later.
- Splitting off things that depend on xlibs and/or perl-tk seems to make
sense, even with modular xlibs.
- I don't think, however, that splitting off things that depend
on perl generally is worthwile; because of dpkg-dev perl is
build-essential, anyway. Similarly, the new ConTeXt scripts written
in Ruby deserve a Suggests: ruby, but not a splitting.
- All binaries in /usr/bin make up to 6.5Mbyte; xdvi.real and mf (the
ones that depend on xlibs) are 764K. From the remaining 5.75MByte,
4.7 are from big binaries with sizes >= 100Kbyte, but in fact most
build-depending packages only need pdfetex, mf(-nowin) and dvips,
together 1.3Mbyte (all numbers are from teTeX-3.0), plust many of the
small executables.
Thus, we get
* minimal scheme
^^^^^^^^^^^^^^
tetex-bin is split into tetex-bin-nox and tetex-bin-x11; tetex-bin
continues to exist as a dummy package. Besides sorting files with dh_*
and writing the necessary control information, the only thing we have to
do is connected to mf: we probably need to set up an alternatives system
for mf-nowin and mfw.
* advanced scheme
^^^^^^^^^^^^^^^
Additionally, tetex-bin-nox is split into tetex-bin-mini and
tetex-bin-extra (or similar), where tetex-bin-mini contains only
pdfetex, mf-nowin and dvips plus the needed scripts/binaries smaller
than 100K. This would require more work, because finding out which
small programs are needed isn't trivial.
* for tetex-bin, I would also find it acceptable to not split it
further.
3.2 tetex-base
For tetex-base, the additional splitting-off of a type1-fonts-x11
package can be added to both following splitting schemes:
* minimal scheme
^^^^^^^^^^^^^^^
Just move PSNFSS and the Bluesky fonts to tetex-base (e and d, #324868,
#302035) and be done.
* advanced scheme
^^^^^^^^^^^^^^^
Alternatively, we could create a tetex-base that is in fact a
latex-base:
As Ralf has pointed out, tex/latex has a size of 16Mbyte, while 94Mbyte
of the total of 135 Mbyte (without doc) are in the fonts directory.
Therefore it seems that it doesn't help much to figure out which LaTeX
packages are needed in this new base package. Instead, we include in it
- the complete tex/latex directory,
- everything else that is needed to run LaTeX
- input files for makeindex and bibtex. I'm not sure about all those
bst files.
- PSNFSS fonts, the CM and EC fonts in Metafont and Type1 format, if
available.
This should be enough to build packages using texinfo or sgml-to-LaTeX
converters (or other frequently used something-to-LaTeX converters).
tetex-extra gets all the rest.
In case we end up implementing the advanced scheme for both source
packages, we also need to think about dependencies - I think in this
case tetex-bin-extra should *depend* on tetex-extra, so that people
won't end up with texexec but no context input files, and similar
situations.
Maybe we should also rename tetex-base (e.g. to tetex-latexbase), but on
the other hand I don't expect that many packages that depend on
tetex-base only would stop working; the harder part would be to convince
package maintainers to drop the tetex-extra dependency.
In any case, I suggest that tetex-base should create a tetex-complete
package that installs everything (maybe except the X11 fonts).
4. timeline
========
Quoting Adrian Bunk:
THE RIGHT TIME FOR SUCH A SPLIT IS SOON AFTER A RELEASE.
(No, he didn't shout so loud, that's me.)
Now is the time for discussion and to speak up when something is so
important to you that you are offering to spend time on it. Please
speak up if you agree or disagree, or if you want to propose something
different.
If you like, we can start coding at once, using a branch in the svn
repository. An upload to unstable should not happen until the teTeX-3.0
packages in their current state have stabilized in unstable, and we are
no longer busy fixing other people's bugs (like xmltex, and for sure
some documentation-related FTBFS bugs).
Regards, Frank
[1] http://www.de.debian.org/Bugs/Developer#subscribe
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
