LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Wed, 11 Nov 1998 21:58:09 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (89 lines)
Phillip Helbig writes:
 > > > I cannot speak for the others, but i would very much welcome an agreed
 > > > "recommended" level of packages above the base level, so that one can
 > > > stop saying to people "oh, sorry, you have XXXtex, they dont ship
 > > > package ZZZ"
 >
 > Yes, this is the problem.

okay that's the problem, i think we all agree so far, but knowing this
is unfortunately not a solution in itself

 > > I wonder if it would not be possible
 > > to lay down a fairly strict protocol
 > > governing "acceptable" packages,
 > > so that one could automate downloading?
 > >
 > > At present one actually has to read the README
 > > to find out what to do
 > > (eg put associated font files in the right place).
 >
 > Right.  A pain.

there is a possibility to define such a protocol but it needs to be
defined!

there have been tries in the past to get things normalised but they
all died a natural one

a possible scenario as far as installing into different directories is
concerned is to make use of a docstrip feature that was added some
time ago (docstrip can actually write to different directories which
could be specified via variables, so one could have a systemwide
docstrip configuration file and packages just have to tell that such
and such files belong to the "inputsdir" and other to the xyzdir ...)

 > I think the solution is to put more stuff in the core part.  One can
 > actually automatise updating the core quite easily.

perhaps you should reread my message, this is neither simple nor
something that should grow a lot over time, otherwise a core from 199x
will not be able to process files written for core from 199x+1


 > To sum up, get rid of contrib/supported.  If it's supported, it should
 > go into the core.  Perhaps one needs a filter here to avoid redundancy

no!

a) the word supported needs to be clearly defined. people have totally
different opinion what they mean about they support their work

b) i'm against enlarging the core step by step as this is against the
portability rule outlined before


 > in the core and assure quality, but basically if it's good, someone has
 > taken the effort and is supporting it, after this filter why not put it
 > in the core.  There is then core and everything else, which can be like
 > a trial area.  Gradually core can grow.

i'm much more in favor of a twofold approach:

 - a core that stays stable (perhaps larger than now, eg officially
adding a certain set of packages to it if they get converted to a
standard installation and maintenance procedure and have a clearly
defined support structure)

 - a recommended package set which is allowed to grow and or change,
ie package dropping out which is maintained by a volunteer group who
looks after the fact that the package obey certain installation
standards (like in the core) so that installation of package in that
area is easy, have some maintenance and support. this group would also
make decisions which packages are promoted to go into that group.

in any case any such scheme should fullfil the requirements that i
outlined in my previous mail possibly more

frank

ps RPM is not an option in my opinion; the installation process has to
work on any TeX installation which essentially means on any platform,
so unless somebody intends to write install-shields for each and every
OS (and maintains them) the only program you could expect to be
available everywhere is TeX itself. this is why we have chosen to have
the installation fully based on docstrip which even if it is slow was
in my opinion the right decision. (but as i said we had plans to make
docstrip smarter and this is actually available even if it is not yet
used)

ATOM RSS1 RSS2