texlive5 plans

[Sebastian Rahtz]

Following some conversations with Debian people, I am wondering about
proposing to `manage' TeX Live as a set of Debian packages. The idea
would be to redefine the existing Debian  teTeX distribution (with
Thomas' help!) and make a clear distinction between five types of TeX 
installation
 
 - basic:     the minimum needed to eg process texinfo documents and print 
              them, or simple papers using CMR
 - normal:    what an average LaTeX user needs, plus some extra programs
 - advanced:  a lot more packages and fonts, plus some moderately
              strange programs
 - guru:      all the obscure things that we use every day, and the
              silly programs we have never used (like mft)
 - languages: a set of language/script packages

"basic" and "normal" would be provided by teTeX, as at present, and
texlive would provide the "advanced" and "guru" addons. "languages"
would be extracted from both teTeX and classified
separately. Obviously, many languages would have a dependency on
"normal", but a reasonable person might elect "normal+french", while
another might want "advanced + french + italian + greek"

within the first four categories, we keep the 15 or so divisions as at 
present:

bibtex doc dvips etex fonts formats generic graphics latex metapost
omega pdftex plain systems texlive

All this would mean 50 or 60 "packages", plus 10 or 12 language
packages. In addition, obviously, we have some "virtual packages", so
in practice some one just asks for "tex-normal" and "tex-french"

What are the practical implications of all this?

a) The TeX Live CD stays as is, a TDS tree of all the above
b) The packages are generated from the master TL source tree
c) In between CDs, we can maintain more granular updates 
d) We need to do a lot of work in moving things around packages
e) We have to derive basic dependency information

The advantage is that Debian and FSF get a more complete free TeX
setup, and it is not an impossible task because we already have the
named packages in place.

Obviously this would be a lot of work, but I have always felt that
cataloguing and packaging were the big challenge ahead, and I'd feel
happier doing it in the context of an existing project like Debian.

I would stress, of course, that the `Debian package' is (if all goes
well) only one example of an output. Making RPMs or even .tar.gz
should be trivial once the structure is in place.

So unless you think I am whistling in the wind, who feels able to
devote some time to moving packages lists around and writing
management scripts....?

Sebastian