[tlbuild] duplicates in win32

Vladimir Volovich vvv at vsu.ru
Mon Jun 14 18:16:20 CEST 2010


"GNW" == George N White writes:

 GNW> Some sites have the texmf trees on shared, noexecute, storage.
 GNW> Others will systematically disable execute permissions in "data"
 GNW> directories.  Perhaps wrappers that give the script as an argument
 GNW> to the appropriate program are needed for all platforms., not only
 GNW> Windows.

apparently, unix bin directories are already extensively using symlinks
in the bin trees (and nobody reported it as a problem, at least into the
texlive mailing list, as far as i remember). those few large sites which
use such unusual setups with nonexecute storage for texmf tree, could
just replace symlinks with 1-line shell wrappers.

 >> installing them as symlinks would:

 GNW> (or using wrappers)

 >> * save some space (only one copy of the script, instead of
 >> duplicating  it in each binary directory; and some of them are quite
 >> big)
 >> 
 >> * avoid possible synchronization problems, when different
 >> architectures  get outdated copy of some script

 GNW> And:

 GNW> * eliminate the need to update binary packages for all the <archs>
 GNW> when a script is changed.

 GNW> * simplify the problem of sorting out messy hash-bang lines (if
 GNW> the scripts are not going to be executed, the first line can be a
 GNW> comment indicating the "language", e.g., perl, ruby, etc. ).

if we're going to do such change, why not simply put a hash-bang there?

but as far as i understand, we can't afford to change every single
upstream script (if it is not using a hash-bang already), because of
maintenance problems (need to remember to change it every time the
script is upgraded).

 GNW> This can be used to automate the task of assigning the appropriate
 GNW> wrapper to each script.

also, symlinks are just executing the script quickly. on the other hand,
if we'll be using a wrapper on unix, which would search and analyze the
scripts in the texmf tree, it will unnecessarily slow things down.

Best,
v.


More information about the tlbuild mailing list