[tex-live] suggestion for texlive install
George N. White III
gnwiii at gmail.com
Sat Jan 27 15:58:51 CET 2007
To add my own viewpoint to Karl's comments, there are things that need
to be done to improve the chances that we will have good linux
packages maintained by vendors, and things aimed at minimizing the
divergence between WinNN and linux/unix/OS X. Linux and some unix
users who have never heard of TeX, or those who have had bad
experiences with it in the past and swear they won't touch it ever
again end up getting it thru package dependencies, and even running it
without realizing when rebuilding or installing packages.
On 1/25/07, Karl Berry <karl at freefriends.org> wrote:
> May I suggest that install-tl.sh (or its equivalent) check whether there
> is an existing tex application somewhere first?
> I think that would be a good idea, and it would give us a chance to
> explain some of the facts about "native" TL installation. I'll put it
> on the list for next time.
Except for the people who just did a default linux install and
probably didn't know what TeX is, or had to install it for some
package dependency, most users who use it will know if TeX is already
present. The big issue is that many users are very nervous about
changing TeX. They had a big battle getting the last install to work,
aren't comfortable with admin tasks, and have a multi-year project
like a book and have been writing papers using the template they got
from their advisor in grad school. Many of these people started in an
environment where TeX was installed by the local guru, so never had to
worry about texmf trees until linux became popular. They have
deadlines to meet and can't afford to spend time figuring out why
their document gives errors with a new version of TL.
Users have often updated macros that will be older than those in
TL2007. You can't predict where these will have been installed --
some user overwrite portions of the main texmf tree, some use
$HOME/texmf and some use a texmf-local tree. To sort out problems it
is useful to be able to run the old and new systems side-by-side until
the new one has been beaten into accepting the user's documents.
This is quite feasible with the single tree model of real tetex and
texlive, but problematic with package managers. I know people who
buy a new machine when they need to upgrade TeX. It is now quite
practical to us a virtual machines to do this, but the people who need
it don't have the admin skills to clone their old environment into a
VM where it can be preserved, so it may still be more practical to buy
new hardware every couple years.
> the install could ask the user whether texlive install
> The only thing the TL installer can do is abort. There's no feasible
> way it can delete installations, which could require running OS
> packaging commands, etc. Besides being way too dangerous just on
> there exist tex packages that are being superseded by newer versions
> An "updatable" TL has been discussed at monumental length. Perhaps we
> will make progress on it some day. Meanwhile, those using Debian and
> other OS-level packaging systems already have it.
The MikTeX package manager is useful in a mixed Win32+MikTeX and
*n*x+TL environment. MPM can be used to manage a texmf-miktex tree
for MikTeX versions of packages that need to be updated for
consistency with MikTeX (which tends to be conservative about versions
of the programs but tracks CTAN package updates).
My impression is that TL has very limited acceptance on Win32.
It is used by people who need WIn32 but are more often found using
*n*x and want to have the same texmf tree on both platforms.
Would if be feasible to translate between tl and mpm packing so
tlpmgui could be used to apply miktex updates?
> This year's shell script installation is essentially unchanged from the
> way it's always been. There are plenty of deficiencies with it, and
> I hope someday there will be enough time and energy to improve it.
Time and energy has gone into tlpmgui. It needs lots of testing to
work out the glitches, but without updated packages it will suffer
from only being run once each 1.X years to install a new TL. Maybe
people use it when they discover they need a package they didn't
install first time around, but it is pretty simple to just unzip and
run mktexlsr (and a user without root privileges can add things to a
texmf tree they control -- can tlpmgui do that?).
Time and energy has to go to making sure that TL works well (in
particular, TL shouldn't break existing packages that use TeX) so
users and ultimately vendors will see it as the successor to tetex and
adopt it as the basis for their distribution packages. Since vendors
are going to package TL by their own rules, they will ignore any TL
provided installer. The debian packaging helps a lot because many
developers in large projects (e.g., R, the S+ clone) that use TeX for
documentation are using debian and because it shows how the
single-tree model can be adapted to packaging. If texlive displaces
tetex on debian, commercial vendors will (eventually) follow. So time
and energy needs to go to making the debian packaging work well, even
to the point of including debian-specifics (texmf.cnf management) into
The shell script installation is adequate for admins who need to
create a multi-platform texlive tree that can be shared across a
heterogenous network of workstations via a file server or rsynced onto
Many sites will want to build shared-library versions (so they don't
have to rebuild every time a library has a security issue). The
configure scripts, source tree, and cross-platform scripts are a key
part of making texlive a viable option for use in centrally
administered sites and linux distributions.
Security perceptions (in particular, using the "right" libraries and
interfaces so automated tools don't raise alarms) and better support
for the full range of languages (including translations of the
documentation and searchable pdf's) are important for wide adoption.
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
More information about the tex-live