I'm back (I think :-)...

[Joachim Schrod]

Rich wrote:
> 
> I am still quite interested in the idea of a Registry for TDS names, but
> I never got much (read, ANY) reaction to my specific proposals from the
> TeX wizards out there. 

Oops, I have forgotten to forward to this list a discussion I had on
comp.text.tex. It started with the question of easier TeX
installation, and I presented the TDSR idea as a means to get
automatic installation. I append my old article below, FYI.

For the record: 5 people reacted. 3 thought that the whole hassle is
unnecessary anyhow, and 2 agreed to my proposal. Neither the amount
nor the tendency of this reaction encouraged my to follow this path
further.

Executive summary: Compared to Rich's proposal, I would prefer a more
high-level description, where the directory information may be deduced
from automatically and where the information doesn't need updates more
often.

Cheers
	Joachim

---------------- included article follows:
From: schrod@iti.informatik.th-darmstadt.de (Joachim Schrod)
Subject: Re: Installing LaTeX2e: A Suggestion
Newsgroups: comp.text.tex
Distribution: world
Followup-To: 
References: <jhh.804928700@news.cwi.nl> <3tdn05$kl2@hippo.shef.ac.uk> <3te83q$dcm@news.rwth-aachen.de>
Organization: TH Darmstadt, FG Systemprogrammierung
Keywords: 

In article <3te83q$dcm@news.rwth-aachen.de>, dak@tabaqui.informatik.rwth-aachen.de (David Kastrup) writes:
> 
> Now, the TDS standard committee is cooking a file structure up for
> all of us, suggesting what should go where. It would probably be not
> the worst of ideas to include a file
> tdsinfo
> in every distribution which specifies where this distribution wants
> to have all its files distributed to.

Very good idea. (A set of such files makes up the yet-nebulous idea
of a TDS registry that is mentioned in appendix A.2.)

> Somewhat along:
> *.ins: &latex
> *.drv: &latex
> wusel.dtx: &latex
> *.cls: tex/latex2e/packages/fulcro
> [...]

Hmm, you could just name the directories relativ to the TDS root
texmf. [footnotes *1 *2]


But let me bring up a similar, but different possibility: a more
high-level description. I.e.:

----------------
Bundle: foo			% `Bundle' is an alias for field name `Package'
Category: latex			% from a predefined set of categories
Run-Files: *.sty *.fd *.fmt	% files needed at run time, to use it
Doc-Files: *.dvi foouser.tex README % files with _user_ documentation
Font-Supplier: public		% see TDS, section 4
Font-Typeface: drake		% logo of Sir Francis Drake Society :-)
----------------

This information is enough to install a distribution automatically in
a TDS tree. Of course, if some field is not appropriate, it should not
be mentioned. One can establish known abbreviations, too. E.g., the
`Run-Files' field could only mention $latex (or @latex) and this will
automagically expand to a list of known-extensions-from-the-LaTeX-world.

IMO this description is better as the file based one, as it not only
carries information for the installation program, but also information
for the human that wants to have an overview about the contents of that
distribution.

Of course, support for the interpretation of such a description is up
to the respective TeX sub-communities (the Unix, DOS, VMS, etc.,
camps).


I would like to get feedback for that idea, please post or send
comments. There has been discussions about a proposed minimum standard
for supported LaTeX bundles. The current result of this discussion is
available as ftp://ftp.th-darmstadt.de/pub/tex/latex/bundle-dist.tex.gz .
I'm currently working on Perl scripts that will help to check incoming
CTAN submissions for compliance with these guidelines and to ask
authors for improvements in their next release... (They have been
written already, I'm in the test phase.)

These guidelines already demand a CATALOG file with information about
the bundle. We could add easily fields like those outlined above.
Even make them mandatory?!

The CATALOG file can be an input for the planned TeX Package Registry,
discussed recently on this newsgroup.


So -- if any authors of packages are still reading: Would you be
willing to add such a file? Please send me mail or post. If enough of
you authors -- yes, We Want You :-) -- are willing to add such a file,
I would fix a proposal for a format.

A Perl script for the installation job can be written very quickly.
    As an aside note for the non-Unix user community: Perl is
available for many other platforms. If you don't have it, please
don't complain about Unix-centrism. Add _your_ volunteer contribution
to the TeX community and write an installation system that interprets
a file like above. Use a system that is well known and wide spread in
_your_ user community, be it REXX or Visual Basic or whatever.


OK, one last remark:

> Note that this looks suspiciously similar
> to make file syntax [...]
> So one could probably even use plain old makefiles, and not many
> people suffer harm from that.

I don't think that's possible. To write portable Makefiles is a pain
in the a**, even if you generate them with sed (aka GNU autoconf) or
cpp (aka Imake). You won't use the up-to-date-check feature of make
anyhow. And in the actions you'll need commands that are the same on
every platform: on Unix, DOS, VMS, etc. That some make is available
there as well doesn't make the Makefile portable. I'll would enjoy to
get proved wrong -- but I fear that's a bite too big to swallow.


Cheers, -- and send in your comments to these remarks

	Joachim


----------------------------------------
Footnotes:

[*1] As there has been already the reproach of Unix centrism in this
thread, let me please note that the notion of `a/b/c' for a file in a
directory hierarchy is not a Unix-only notion. (It certainly has its
roots there.) It's the notion used in the ISO/IEEE standards for
Portable Applications. Of particular relevance is the standard ISO
9945-1 `System Application Program Interfaces' (aka IEEE 1003.1).
That standard is nowadays available on many platforms, including DOS
& VMS. (It's even there on MVS.)


[*2] Some more comments on the content of the proposal, maybe I
didn't understand it completely:

> *.ins: &latex
> *.drv: &latex
> wusel.dtx: &latex

Hmm, what does `&latex' mean here?
These files should be available in

source/latex/<bundle>/

where <bundle> is the name of the distribution unit. (I.e., the
subdirectory from contrib/{supported,other}/) and the files should
just stay there.)

> %what syntax for makeindex files?

*.ist: makeindex

> *.cls: tex/latex2e/packages/fulcro

*.cls: tex/latex/fulcro		% no packages/ subdir :-)

> *.dvi:

*.dvi: doc/latex/<bundle>/	% maybe doc/latex/misc/


--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod			Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany