Yuri and all,
I've been monitoring this thread for a while.
Using package/ports management systems is a good idea, but...
teTeX can be built by the standard ./configure, make, make install.
There are many computer platforms and almost as many package/porting
systems. These systems are often very much incompatible with each
other and using more than one on a machine can lead to major
problems. As a Mac user I read the mailing list for DarwinPorts, the
currently largest Mac OS X/Darwin ports system in terms of number of
available packages. There recently was a lengthy thread on variants
versus dependencies. To recap this in short: unless the packager
builds a "plain vanilla" version you end up with astronomical numbers
of variations on dependencies. Note: Both DarwinPorts and Fink list
teTeX 3.0 ports. There is no mention of TeXLive.
For my needs a small package such as the present teTeX is more useful
that an expansive TeXLive. Many of pieces of software I install on my
own machines need TeX for building documentation (e.g. octave).
Asking the end user to download the equivalent of a DVD or at the
very least a CD, or for that matter have their computer build
something this large, makes no sense to me.
What I need is to be able to pull via ftp/http or from cvs/svn a
(sub-)tree that I can compile as above that provides the equivalent
functionality of teTeX.
On Jun 1, 2006, at 8:14 AM, Yuri Robbers wrote:
Hello Giuseppe and others,
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.
Marius
--
Marius Schamschula, Alabama A & M University, Department of Physics
The Center for Hydrology Soil Climatology and Remote Sensing
http://optics.physics.aamu.edu/ - http://www.physics.aamu.edu/
http://wx.aamu.edu/ - http://www.aamu.edu/hscars/
