[tex-live] Re: Debian-TeXlive Proposal II
frank at kuesterei.ch
Mon Jan 31 19:44:33 CET 2005
Hans Hagen <pragma at wxs.nl> schrieb:
> Frank Küster wrote:
>> You mean, you suggest that we move all files to TEXMFMAIN, but create an
>> empty directory referenced by TEXMFDIST? What would be the benefit of
>> this approach?
> safeguard for user updates
>> Local administrators should never put any files below /usr/share on a
>> Debian system, and Debian packages shouldn't use TEXMFDIST, either. What
>> would I gain by starting to support TEXMFDIST?
> actually, since your starting point is tex live, you're talking about
> dropping texmf-dist, and that's just asking for work; it does not hurt
> to have that empty dir
No, I don't think so. We are talking about Debian packages for
tex-live. A Debian user who installs these packages for the first time
is in one of two possible situations:
a) he did not have tex-live installed before (i.e. used tetex or
nothing): There's no TEXMFDIST on his system.
b) he previously had tex-live installed manually (i.e. without a Debian
package): He has some TEXMFDIST, but this must be some directory
ah, actually there is a third one:
c) he previously had tex-live installed in /usr/share with a home-made
Debian package. There are files in TEXMFDIST, but they will
automatically be removed and replaced by the ones in TEXMFMAIN.
For the case of b, we could consider to add the tree, there you are
right. But this wouldn't be TEXMFDIST, but rather something like
TEXMFDISTLOCAL, if not TEXMFDISTOLDLOCAL. And while I think about it, I
don't think that it will cause much good: Either it comes after
TEXMFMAIN, then it doesn't have any effect. Or it comes before it - but
then the system will for ever stay in the state of the old installed
tex-live texmf tree, no matter how recent the version in the Debian
Am I misunderstanding something, again?
> imagine a user who downloads something from the internet (user group
> website, ctan, whatever) which is packaged (zipped or so) in the
> texlive directory structure using texmf-dist); normally the root tree
> is not part of such a package and so users will install in
> texmf-local, but there is no danger in providing the dist-subtree as
If a "something" is packaged to extract itself into texmf-dist, it's
broken, anyway, isn't it? If we have the ordinary tex-live setup with
texmf-dist, these additional files will be removed by the tex-live
upgrade, anyway - that's what texmf-dist is for, isn't it?
So for a user of tex-live, the files would be lost after the next
upgrade of the distribution. For the Debian user, the files will stop
working as soon as he installs the Debian package (because they will no
longer be found), but they will still be present (unless he has done
havoc to his system and installed into /usr/share/texmf - then they will
be kept and found as they are).
>> P.S. The reason why Debian packages must install add-on files into the
>> same trees as tetex/tex-live does is that it would generally be a bug to
>> shadow a file provided by the main TeX package. If packages generally
>> installed files into a different tree, I fear such bugs would occur
>> frequently, between teTeX/tex-live and add-on packages, or between two
>> add-on packages, one of which installs into TEXMFMAIN, the other into
>> the new TEXMFDIST.
> normally users will update in texmf-local or in a $home based tree;
> but you cannot be dure of that, so things may end up in the place
> where users think they belong, for instance because the manuals tell
Do the manuals tell people to install into texmf-dist? I thought the
purpose of this directory would be to be able to completely remove it
and replace it by the new release.
> concerning bugs ... installing a linux-package (from distributer) and
> tex live (from user group cdrom) on one system never worked well,
> users can best best stick on one or the other [and spraking from the
> user groups point of view, i.e. support, the closer one sticks to
> texlive or miktex, the better)
So we don't need Debian packages of tex-live... Well, some people seem
to want them; and then we should build them in a way that installing
additional packages does work.
>> We do consider to provide an additional tree for packages that
>> deliberately want to provide newer versions of input files than in teTeX
>> (or tex-live), especially for things that are under heavy development,
>> like the experimental to-be-LaTeX-3 packages (xkeyval...), or perhaps
>> new things like beamer.
> as long as it's not called texmf-extra since that one is already taken for goodies
No, I was thinking about something like texmf-site, analogous to the
Debian naming of /usr/share/emacs/site-list and /usr/lib/site-python,
for Emacs Lisp files and (byte-compiled) Python scripts that don't come
with Emacs or Python themselves.
> yeah ... sysadm's ... my experience is that they don't like updating
> tex; for instance, installing tex live on a system that already has
> one of those old tex trees laying around [one that got installed when
> installing the system] in a pain;
This is probably different for sysadmins of Debian systems. They are
used ot old software, too - because Debian stable could as well be
called stale. But if the release update comes, they usually update
> the average user - if already aware
> of how tex hooks into his/her system -
> is not able to figure out why old trees are found while new ones are
> installed, for instance because profiles have hard codes paths to
> them, or because texmf.cnf is not located under a web2c path but in
> etc or so;
This doesn't seem to be an issue in a properly configured Debian
package. There's one HOMETEXMF for every user which works out of the box
- not more and not less -, and in teTeX 3.0 there will be TEXMFCONFIG
which additionally supports creation of user-specific formats.
> PS. imagine what happens when users who have a working system update
> from their standard installation to tex live (incompatible changes in
> 2005) and after that using tetex 3.0 repackaged by debian; right now i
> start getting reports about such messed up systems and the best advice
> i can give those users is to buy a new machine dedicated for
> typesetting, and keep it far away from uncontrolled opdated -)
Well, what is going to happen for sure is that the files from the tex
live standard installation become invisible unless they are in
/usr/local/share/texmf. If they are there (are they?), there is a
problem. The package installation procedure will have to check this and
urge the sysadmin to remove them. If they are elsewhere, they just
become invisible - which is intended.
Inst. f. Biochemie der Univ. Zürich
More information about the tex-live