[tex-live] [tlpmgui] tlpmgui starts in the wrong mode under Win32

George N. White III gnwiii at gmail.com
Fri Feb 2 16:22:12 CET 2007

On 2/2/07, Philip Taylor (Webmaster) <P.Taylor at rhul.ac.uk> wrote:

>  > 2007/2/1, George N. White III <gnwiii at gmail.com>:
>  >  > Some do expect exactly that.  Since the locations of texmf trees are
>  >  > tied to the location of the executable [...]
> I would be very happy if this behaviour could be phased out.
> For what I think are very obvious reasons, I prefer to
> keep executables and data in very different locations,
> and in practice on separate partitions and even on separate
> hard drives.  The present system (which is admittedly
> no different to Microsoft's equally insane view of the
> world) perpetuates the philosophy that it is normal
> for both programs and data to share the same space;
> IMHO, this is an ill-conceived idea which should be
> phased out as quickly as possible.

There are situations where the Single Tree (ST) approach is helpful
(so you can switch between TL2003, ..., TL2007) simply by updating the
path, and situations where it is helpful to follow the "Filesystem
Hierarchy Standard" (FHS).   Note that for this to be realistic, ST
needs static linking, while the people who advocate FHS also tend to
need dynamic linking.

Certainly nobody is in favor of a system that doesn't allow removing a
TL installation.  With the ST approach, you can just "rm -r" the tree.
 With FHS most people need a package manager (rpm, dpkg, etc.) or
chaos will happen.  TeX is a difficult problem for most existing
package managers (on SGI, there was a freeware teTeX package that
depended on every other 3rd party package in the known universe, so
you needed gigabytes of disk and days of installing just to be able to
run "tex story").  The ST model has the advantage that it can be
installed on lots of platforms.

This thread started with the problem of locating an existing tex
installation for an ST  package manager.  It would be nice to have FHS
packages for TL, but I think the most that TL can do is ensure FHS and
related needs (dynamic linking) can be accommodated without forking,
and that TL can be used as a teTeX replacement (e.g., doesn't badly
break existing docs that compile with tetex).

There is another goal that needs to be mentioned more often: avoiding
things that will create confusion among users and raise noise levels
on c.t.t, etc.  There is a problem
with ST TL being installed in parallel with other TeX systems.  I see
system with parts of Y&Y TeX, 4allTeX, MikTeX, etc either incompletely
removed, or copied from some old machine after some document failed to
compile with the current TeX.  The ST approach has the advantage that
it can be made to work in the presence of such remnant installs.
FHS installers can't all be trusted with uninstall, while 'rm -f' can
be usually be trusted to remove everything the user hoped to remove
and more besides.

George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia

More information about the tex-live mailing list