[tex-live] Matching TL package setups to my own

Gerben Wierda Gerben.Wierda at rna.nl
Thu Aug 23 16:31:46 CEST 2007

TL distribution is currently organized like a tree with objects. There are
the following categories:
- Documentation
- TLCore
- Package
- Collection
- Scheme
However, these categegories are just names, the structure of all these is
essentially the same (TLPOBJ). The basic idea (as I can gather) however is
- Schemes are made up of collections and may depend on other schemes
- Collections are made up of packages and may depend on other collections
- Packages (Documentation, TLCore and Package) may depend on other
packages and contain lists of files to include.

But this is not enforced. Scheme-gust and scheme-tetex for instance depend
on both Collections and Packages directly. It is also no problem to add
files to a scheme or collection directly and in fact
collection-langcyrillic has files. Hence, while Package CJK and Collection
collection-langcyrillic both have files and dependencies, one is a Package
and the other a Collection.

I have been thoroughly confused by all of this. This has made it time and
again for me impossible to quickly implement TL structure support for my
OS X installer. This installer has a very simple setup: there are chunks
(these contain files) and there are sets of chunks. I need to improve on
that, but TL's structure is not a logical basis for that and creating
something usable would mean ad hoc implementations based on knowledge not
on structure and any future change would render the solution probably
invalid, resulting in high maintenance levels for the installation.

I would like to propose a change for TL structuring such that relation and
use are enforced and thus installers need no special knowledge but can
rely on structural information in the TLPDB.

First, my suggestion would be to drop theb difference between schemes and
collections. Just have collections. collection-tetex is just another
subset of TL (but see below for schemes).

I would also drop the difference between TLCore, Package and
Documentation. After all, while it is true that TLCore should go to texmf,
Package to texmf-dist and Documentation to texmf-doc this information is
also already there in the file lists. Hence, I could currently easily put
a texmf-dist/foo/bar file in a TLCore package and it would just work.
Having these three categories *and* the subdir info in the setup is
redundant. Having them also not enforced by structure is a possible source
of confusion.

In other words, I would like to simplify matters.

I think we have in fact just one thing (as reflected in TLPOBJ), a TL
'object'. This needs a useful name and 'collection' would do. Subset would
do as well. Maybe something better could be found.

Collection-langcyrillic would then be a TL subset the same way CJK is a

We could still tag the subsets with properties. Scheme could be such a
property. A scheme would mean that it is a high level subset that is
proposed to be user-selectable in some sort of installer at the 'overall'
level. Instead of Schemes and Collections we would have collections only,
but some of which would count as user-selectable high level installs.

I was also wondering if all subsets should have complete dependencies.
Take current Package CJK. It does not depend on collection-latex. But
without latex it is unsuable. It seems currently, many packages have a
status of "Addition" with an underlying (and thus external
responsibility). I think it would be better if CJK would depend on

Furthermore, I think it would be good to have some sort of version
checking for dependencies. The new beamer may depend on a newer version of
pgf. Suppose the newer version of pgf is not available, an installer
should have to refuse to install beamer unless pgf was the last version.
Given the state of TeX contributions, these versioning should be set up in
the TLP setup (and hopefully migrate back to maintained contributions).

This is all 'thought in progress', but this is the third time I have been
looking into building my redistribution on the basis of TL structure
instead of the rather rough and unintelligent way my stuff is now put into


More information about the tex-live mailing list