Re: What I miss in teTeX

george white writes:

> Quoting Robin Fairbairns <[email protected]>:
> 
> > VnPenguin wrote:
> > > IMHO, Installation/uninstallation TeX packages is not a _daily_ job.
> > 
> > if it's a rare requirement, people won't remember from one time to the
> > next how to do it, so the problem remains in perpetuity.
> 
> Speaking for myself, there are getting to be too many installers.  Unless
> the installer uses the platform's std. installer (apt on Debian, rpm on
> RHEL, tardist on SGI, msi on Win32) I'm probably going to have to 
> RTFM anyway.  Sensible people who stay on one platform will also appreciate
> something that works with the default tools.  The hard part of installers
> is managing dependencies, which is hard to do without the help of the native
> tool.  If you look closely, teTeX depends on many 3rd party packages, including
> ghostscript, imagemagick, xpdf, ... 
> 
> 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.

> 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.

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.

> > 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.

> > 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.