Re: What I miss in teTeX

Quoting Robin Fairbairns <[email protected]>:

> george white writes:
> [...]
> > Most linux distros have tetex packages, so the issues are:
> > 
> > 1) problems with the vendor packages being broken or changed beyond
> > recognition, and  
> > 2) installing add-ons at the granularity used in TeX-Live
> > 
> > I expect issue 1) is best addressed thru the vendor bug-reporting,
> 
> a nice idea, but (a) i've seen no sign of any activity from any but
> debian people in tex lists, and (b) my experience (with redhat) is
> that input is ignored by the distributors.  otoh, i have seen activity
> from debian tex package maintainers.

Redhat did address the documentation bug I filed over their inclusion of ptex
in the tetex package for FC4.  In general, I only expect the TeX in a distro to
be able to format docs in the src rpms, so I don't file bug reports over
outdated
packages.  For real work, I start  with TeX Live because fewer packages will
need to be found and/or updated.   

> > but
> > in principle it should be possible to produce replacements if the vendor
> > is slow to respond.
> 
> sure; i have rpms for packages that my people need.  i expect that
> other sysadmins have rpms for the packages that _their_ people need.

Not on this side of the pond.

A major cultural divide that has come between us.  I'm not sure where the
border lies, but in many N. American organizations sys. adms. who have heard of
TeX are mostly promoted to management or retired.  Many sites limit sys. adms.
to
hardware configuration and the vendor supplied packages, with security as the
priority.  I encounter sites where admins who have only MicroSoft training are
trying to manage their mission critical linux machines.  Users are expected to
install software they require.  This is now reflected in the design of the
mission critical (remote sensing) apps we use.  These were once intended to be
installed by root for all the users and are now
designed to be installed by each user, normally on a personal workstation. 
Where once the admin was expected to install regular updates, the apps now do
"on demand" network updating.  There is no locking mechanism to avoid clashes
if two users require the same update at once.   Paranoids would think they are
planning to a switch to windows.

> speaking for myself, there are getting to be too many instances of
> this sort of thing.  and of course, it doesn't help the person sitting
> at home producing his documents: in many cases such people have little
> tex experience, and all these private package repositories don't help.
> 
> > For 2), do you ignore whatever distro-specific package
> > data are available and provide an independent tool for adding things to 
> > "any" tetex that has been installed (e.g., based kpathsea locations)?
> 
> i think it's the only efficient mechanism.  we have limited resources:
> resources, that is, of people who are willing to do work for the
> benefit of the community at large.
> 
> sure, i _could_ make my rpms resilient against installing against a
> different texmf structure (mine is distinctly odd, for historical
> reasons), but what would we do about the debian people, and anyone who
> uses yet another model.

Maybe you make a list of writable trees (using kpathsea), get the user to chose,
then check (each file?) for already installed versions that would conflict,
e.g., why install x.sty in texmf-dist when an x.sty exists in texmf-local?

> > > writing such instructions (with exceptions left, right, and centre)
> > > has led me to believe that an installer is needed.  i've even spent a
> > > little time thinking about how it might work.
> > 
> > As well, I presume, about things that authors could do to make writing an
> > installer easier.  Is it better to have a simpler installer that makes
> more
> > demands on authors or a more robust installer that, with a little
> assistance,
> > handles everything.  Should the installer always install to the main tree
> or
> > can a user install "ad-ons" into a personal tree (e.g., ~/texmf)?  
> 
> sure, i think about authors' contributions.  sebastian rahtz has been
> thinking about them even longer than i have.
> 
> have you ever considered what fun it might be herding cats?  i've
> taken to caring for a cat in place of trying to persuade authors to do
> simple things like document their packages, or to produce them in a
> fashion that seems remotely regular.

In looking at installers for teTeX, the ease of preparing packages should be
given
more consideration than ease of use, since authors are giving something to the
community.  

> > > but now, the miktex package manager is "available for unix"
> > > (www.miktex.org/unx) and when i've a bit of continuous spare time i'm
> > > going to be investigating it thoroughly: this is something i believe
> > > we need.  and here we have it, dished up by a public-spirited person
> > > who just happened to have the basic thing there to start with.
> > 
> > Does the miktex package manager make any provisions for "shared" 
> > installations or is it just for "personal" use?
> 
> if that question is addressed at me, i suggest you read my paragraph
> again.

That question was for the list.  

-- 
George N. White III
Head of St. Margarets Bay, Nova Scotia