nov 15 tds...

[Pierre MacKay]

Alan Dunwell makes good points about the installation of a package
but it probably doesn't really affect the structure of the TDS
as such.

It is more a matter of how the contributors of a package put their
stuff together.  I have just finished my first attempt at putting
together a Solaris package based on TDS, and it leaves me with 
quite a favorable feeling about the Solaris packaging operation.

In TeX's anarchic world, however, I don't easily see how to start
framing the outlines for such packages. It's tricky enough
(and largely undocumented) even in the Solaris environment, and
it isn't likely that it will soon be emulated even across the 
Unix family, let alone out there in the wider jungle.  

The Solaris packaging system is very finicky, and perhaps
rightfully so.  So much so that I do not see any good way of
reading add-ons into the basic package tree structure at all.  
With the aid of
some sort of version control (I am still trying to find out
whether that can be done) it might be possible to put upgrades
into the package tree so long as the earlier file has already been recorded
in the original package installation.  But what Solaris seems to do
is simply remove the entirety of an earlier package and reinstall
on a clean platform.  If the remove doesn't work right, it sulks.
That is why I can't see any good way of infiltrating new stuff
into such a package.  

I fall back therefore on a system of sticking all add-ons
into $TEXMF/local and having $TEXMF/local a link to a completely
separate tree.  I don't see what else to do.  That is not going
to please those who want to be sure that all TFMs are rooted
in $TEXMF/tfm/. . .   especially if they have no capability of
using symbolic links.  They will end up facing exactly what
Alan Dunwell describes, the need to pick through a whole
mess of discontinuous directory trees to install (and even worse
to remove) add-on packages,  a little bit in ./tfm, a little bit
in ./vf a little bit in ./doc a little bit in ./tex and a scattering of
little bits in ./pk or other raster directories.  

If every package came with a map file saying exactly where the
little bits are to be stored and whence they are to be removed
when a new version arrives, much of this problem could be
relieved, but what chance of that is there?  We can urge it,
but it is unlikely to happen soon.  Such a map file could
even make up for the absence of any version control.  Sizes
and checksums could be used to ensure that any file associated
with a version actually belonged to that version.  Needless
to say, the map must be preserved to guide any removal operation.

But it remains that such concerns are probably not directly a
part of TDS itself.  More like a set of unintended consequences.

-- 
%=======================================================================%
|                             N O T I C E                               |
|  Please note the changes in address and telephone number below.       |
|  There is no Northwest Computing Support Center any longer.           |
|  Until further notice, I shall be continuing to provide tape          |
|  distributions  and whatever other services I can.                    |
|                                                                       |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent 
To:     mackay@cs.washington.edu		Pierre A. MacKay
Smail:  Department of Classics			Emeritus Druid for
	Denny Hall, Mail Stop DH-10		Unix-flavored TeX
	University of Washington
	Seattle, WA 98195
	(206) 543-2268 (Message recorder)