[tex-live] private "tl-bin" directory?

George N. White III gnwiii at gmail.com
Sat Feb 17 20:56:26 CET 2007


On 2/17/07, Frank Küster <frank at kuesterei.ch> wrote:

> "George N. White III" <gnwiii at gmail.com> wrote:
>
> > Hartmut's post shows it is not only WIn32 where there are clashes
> > between TL and other executables, so it is worth implementing a
> > general strategy to reduce such conflicts.
>
> I'm not sure that the problems on Windows and Linux/UNIX distributions
> are really of the same type, but I haven't followed the windows-related
> discussions.

Windows problems are very much worse, but the key difficulty is that a
user ends up with multiple programs sharing a name, with potentially
nasty results.   This can happen on *x and Windows, but has been more
widely discussed for windows because many users expect a TeX system to
provide tools such as zip, tar, sed, awk, ghostscript, perl, ruby,
lua, etc. while *x users expect to get the necessary programs from
their distribution.

> > Certain names should be reserved for system-specific use.  Unlike
> > common programs like "ls"and "rm", these would abe allowed to have
> > system-specific behaviour.  Certainly "install" would be in the list,
> > and "install-info" would be a likely candidate.
>
> What do you mean with "system" here?  A particular machine, an operating
> system?

Here, system means the particular distribution, e.g., Debian linux,
Red Hat linux, Apple OS X, Microsoft Windows, etc.   System-specific
behaviour includes the package manager and the way changes to
persistent configuration information are made.   Each system needs to
have a way to protect such tools from clashes (e.g., not using generic
names like "install") because you can be sure some user or developer
is going to use the same name.   How many beginning linux programmers
have been surprised by the results they got after
compiling test.c?

> > In the absence of
> > such rules, Debian should use absolute paths in package installers,
>
> It is an established Debian policy (and a "must" clause IIRC) to *not*
> use absolute paths in install scripts.  And this is indeed very useful;
> for example it's easy to replace a script for debugging, without messing
> up your package database.

But leaves debian vulnerable to name clash problems if you allow
users to install things (for root) without using debian packaging.
Surely there could be a setting that switches between using key
tools from "standard" places (for safety in the real world) and using
the ones you find on the path (for testing).

> > but there is no reason TL can't play nicely by putting install-info in
> > a "private" bin directory, say "tl-bin", for use by TL scripts.   This
> > could also be useful for TL-supplied utilities (unzip, tar, sed, awk,
> > perl, gs, ruby, lua, etc.) on systems that don't commonly have them
>
> That's an interesting idea.  On the other hand, it means that if I
> install TeXLive on a Windows system, I have perl and gs installed, but
> can't use them; if I need them for other reasons, I have to install them
> a second time.

Some tools (install-info) are not required outside TL and should not
be a directory on the PATH where name clashes can cause problems.  Gs,
perl, etc are not so simple.

The TL installer could only install the tools if it doesn't find
suitable existing versions.  But does it do a "standard" install of
standalone gs or
install a gs using the TL installer?  Should a TL install of gs go to
in the bin/WIn32 directory or to tl-bin/Win32?  TL has to work with
widely used versions of standalone gs (to support linux, etc), so it
shouldn't need a private version, and the version TL installs should
have all the capabilities of a "standard" install.  This makes it more
a question of convenience and whether a user prefers TL's installer
over the standard
installer.

Many Windows systems will have the gs installed by the user, the
version MikTeX-2.5 installed, and the version matlab installs.  Matlab
and several remote sensing apps each install a java runtime.

TL's bin directory gets bigger each year, as do the number of 3rd
party apps on the average user's path, so the potential for clashes is
growing.

The key point is that TL can minimize side effects on all platforms by
using a private directory for binaries that users won't normally run
via the command line (nothing would stop some users from add tl-bin to
their PATH).  There could be two install modes: stealth mode where
only a basic set of programs are exposed to the PATH and the way we do
it now.

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


More information about the tex-live mailing list