[tanmoy@gita.lanl.gov: CTAN archives]

[David Carlisle]

I have already replied to Tanmoy pointing at the TDS draft report on
ctan (and the FILES.bydate file)  but some others on this list may
also want to comment....

David

------- Start of forwarded message -------
Return-Path: <tanmoy@gita.lanl.gov>
Date: Thu, 14 Mar 1996 10:13:20 -0700 (MST)
From: Tanmoy Bhattacharya <tanmoy@gita.lanl.gov>
To: David Carlisle <carlisle@cs.man.ac.uk>
Subject: CTAN archives

Hi,

I do not know who to send this to, but I thought you would certainly
know the right person ... so I send it to you. I apologize for this
intrusion. 

I am the resident `texspert' for the e-print database we run at
LANL. Most of the submission we get are in different flavours of tex,
and we actually encourage this format from the authors. As we like to
keep the restrictions on authors at the minimum level compatible with
automatic processing of their submissions, what we receive tends to be
in a wide variety of formats. This poses some special problems for us,
and we are looking to see if we can get some help in this regard. 

Basically, we need to maintain a complete upto-date version of all the
widely used standardized macro packages currently available alongwith
previous versions if the current one is not backward compatible. Even
after thinking long and hard, I could not find any way to automate the
process of upgrading our LaTeX distribution. The base files are fine:
but the contributed software seems to be a mess.

I have three suggestions:

1) Could one set up a mailing list where _all_ upgrades to the
   packages (base/packages/contrib-supported/contrib-others) will
   receive notification. This will at least allow me to upgrade only
   those packages that need upgrading. (Currently I spend a day every
   year upgrading everything!)

2) A `quote site list <date> <root>' command at the CTAN
   sites which lists for me every package in the directory tree under 
   <root> that has changed since <date>?

3) Could the packages be made more consistent? i.e. Require that every
   supported package have a .ins file with the following properties:
     a) It always writes out in a consistent format what files are
        produced and where they should go. A suggestion would be that
        it end with lines of output which say, for example:

           The following files should be installed:
              file.cls  LATEXINPUTS
              file.sty  LATEX209INPUTS
              file.tex  LATEXINPUTS
              file.fd   LATEXINPUTS
              file.mf   LAMFINPUTS
              file.bst  INDEXINPUTS

        It turns out that relying on the extension is not always the
        best.
     b) Instead of (a) a Makefile which includes ../../paths.mk (or
        something similar) and uses no hardwired program or path names
        (i.e. uses $(LATEXINPUTS), $(LATEXPROGRAM) etc.) is an
	alternative.  I would like to be able to not produce 
        documentation: we do not need it ... our authors do :-)
     c) It has a machine readable file which tells me if the change
        from the last version is backward compatible or not.
     d) An unrelated issue: if the package writer knows that the
        package conflicts with others, a machine readable file
        documenting that fact. This should actually be implemented in
        the code (i.e. like RequirePackage, there should be an
        InhibitPackage command).

Could you please pass this on to the right people?

Thanks a lot
Tanmoy

------- End of forwarded message -------