Hello Giuseppe and others,
You describe a serious problem, that - I think - can be solved:
> Please don't misunderstand me. I've not said that TL is bad or I'm
> blaming it. I've only said that it contains much more things than a typical
> teTeX user needs. Regarding packages QA, I don't mean a typical single package
> updates, but usability and conflicts when grouped/used together. If we for
> instance hold a tree where we keep ALL the CTAN LaTeX styles/macros,
> then how to check there won't be conflicts when used together? For
> instance I've styles
>
> A version 1.0
> B version 1.1
> C version 1.2
>
> which are the latest styles available. Then B will be upgraded to
> version 1.5, then we'll obtain a new tree:
>
> A version 1.1
> B version 1.5
> C version 1.2
>
> but for instance style "C version 1.2" is no longer able to work
> with B version 1.1 and give some error. How to check all these
> kind of conflicts? This might be easy if the number of packages|styles
> is small, but as number grows and the update become modular
> this become very difficult, especially if the tree maybe is upgraded
> always and quickly to the latest version.
There already are various elegant (and intelligent) solutions for this
problem.
Examples of such solutions would be the Gentoo portage system and the
*BSD "make world" system. An entire OS with thousands of applications is
managed effectively this way, solving teh dependency problems. SOme of
the drawbacks these systems have will not even exist with TeX.
I'll describe the Gentoo system in a few lines, as it is the system I'm
most familiar with, and will suffice as an example. I will also add
TeX-related notes.
Gentoo portage is a collection of shell scripts that
a) maintain a database of programs , graphics, etc. that can potentially
be installed. (TeX: base system + style files + add-on packages +
fonts, etc.) In this databse is noted for each "program":
- current version(s): multiple versions of packages can be on file,
and can in some cases even be installed simultaneously in order to
deal with dependency issues
- whether a user wants "stable" or "cutting edge development"
versions (overall setting with, possibly, per-package variation)
- architectures it is available for (i.e. processor type). For TeX
this would be the TeX variety: plain, LaTeX, amstex, context,
metafont, etc.
- dependencies (i.e. which other packages are required) which
includes version information (e.g. requires package A, AND
any package B older than 1.2, AND (any C version 3.2 or newer
OR (C-3.0 or C-3.1 AND D))
- incompatibilities (package X and Y are incompatible), or package
X and package Y newer than 2.1 are incompatible, or...
b) update the database from any of a large number of servers (TeX: CTAN)
c) install and delete programs, checking dependencies and
incompatibilities. Programs are then marked as "installed (with
version number)" or "uninstalled" for resolving dependencies.
d) deal with source as well as binary installs.
This system, or the similar *BSD "make world" system could handle
teTeX / TeXlive package management easily. Distribution maintainers
have to note that new versions are available, update the database and
check if it works. After extensive community testing (and perhaps a
bugzilla-like systsem for reportign errors) final adjustments are made
to "dependencies" and "incompatibilities" if needed, and the new package
or new version is marked "stable".
These systems have been shown to work, and several user-friendly GUIs
exist for some, if not all of them. They has a long and succesful track
record including on software distributions that are one to two orders of
magnitude larger than TeX-Live. Maintainers as well as users are happy.
The main drawback is the compilation time of large packages on these
systems when working completely from source (which is optional for many
packages anyway), but TeX-Live doesn't contain all that many large
packages, plus compilation is generally limited to - say - LaTeX-ing
the .ins and .dtx files. And, as has been said, the system can deal with
pre-compiled binaries as easily as with source code. So any package can
be offered as a pre-compiled binary for the system of chocie as well as
as sourcecode.
Of course the main hurdle when using this for TeXlive would be creating
the initial database: this will cost many, many man-hours. But we have a
large community, many people might want to contribute (in fact: it is
not uncommon in Gentoo that end users supply so-called "ebuilds" to
developers for incusion in the database)
Please realise I am not necessarily advocating the use of portage per
se: I am advocating the use of any such system: there are many, and I
think the _general concept_ is exactly what we need: which specific
implementation of the concept we could best use should perhaps not be
discussed until it has been decided whether or not the concept itself
will be used at all.
Comments, anybody?
Yuri Robbers.
