Changes to the Policy (was: SVN tetex commit: r353 - in tex-common/trunk: debian doc)
Frank Küster <frank@costa.debian.org> wrote:
> Modified:
> tex-common/trunk/debian/changelog
> tex-common/trunk/doc/Debian-TeX-Policy.sgml
> Log:
> * Document TEXMFSYSCONFIG in the Policy Draft, and add some more
> clarifications to the text [frank]
There some things in there I'd like to comment on. The full diff is at
http://lists.alioth.debian.org/pipermail/pkg-tetex-commits/2005-November/000404.html
+ <item><file>/usr/share/texmf-tetex/</file>, part of <var>TEXMFDIST</var></item>
+ <item><file>/usr/share/texmf-texlive/</file>, part of <var>TEXMFDIST</var></item>
+ <item><file>/usr/share/texmf/</file>, referenced as <var>TEXMFMAIN</var></item>
With this, I don't want to force a decision to actually adopt this
scheme. But I thought that I'd rather put the necessary changes into
the Policy file, to show how things would fit together (and also to
identify possible problems), instead of putting it into a file on alioth
that nobody is going to read, anyway...
+ The order of basic TeX packages in <var>TEXMFDIST</var> may be
+ changed by the user or by the basic TeX packages, and no
+ implementation may rely on a particular order. This implies
+ that for a package that needs a version of a particular file
+ newer than provided by one of the basic TeX packages, it is
+ not sufficient to declare a dependency on the other basic TeX
+ package(s)<footnote>Of course this is only a problem if the
+ file is needed in the configure phase. If it is needed only
+ at runtime, a README file to instruct the local admin should be
+ sufficient.</footnote>.
This is one of the "problems" I identified - I think this needs to be
spelled out.
all other generated files
should be below <file>/var/lib/texmf</file> (or the
user-specific variable directories), with the subdirectory
- structure conforming to the TDS. If necessary, symbolic links
- can point from static <var>TEXMF</var> trees to files
- below <file>/var/</file>.
+ structure conforming to the TDS.<!-- If necessary, symbolic links -->
+<!-- can point from static <var>TEXMF</var> trees to files -->
+<!-- below <file>/var/</file>. -->
</p>
I cannot imagine any situation where a symlink from TEXMF{MAIN,DIST} to
TEXMFVAR would be needed, and suggest to drop this.
I have also written more details for the case of a package shadowing a
file; without TEXMFSITE they can only shadow files from basic TeX
packages in TEXMFDIST, but I think that if an add-on package wants to
shadow a file provided by an other add-on package, this is a bug
somewhere and not a situation we should arrange things for.
+ A package must not install files into (subdirectories of)
+ <file>/usr/share/texmf/doc</file>, which is a symbolic link to
+ <file>/usr/share/doc/texmf</file>.
I've been bitten by this while testing some unreleased TeX package
(don't remember which); the package will install fine, but an upgrade
that involves transient removal of tetex-base will fail.
I've added that section on configuration files, clarifying our intent
with introducing TEXMFCONFIG:
+ <heading>Configuration files</heading>
+ <p>
+ In a TeX system, in principle every TeX input file can be
+ changed to change the behavior of the system, and thus be
+ regarded as a configuration file. To prevent inflation of
+ configuration files, packages should not install any TeX input
+ files as conffiles or configuration files. Instead, they
+ should create an empty directory below
+ <file>/etc/texmf/tex</file> and advice users which files are
+ likely places for configuration. It is up to the local admin
+ or individual user to place changed copies in
+ <var>TEXMFSYSCONFIG</var> or <var>TEXMFCONFIG</var>,
+ respectively.
+ </p>
+ <p>
+ Note that other subdirectories of <file>/etc/texmf/</file>
+ are not searched for TeX input files and can be used by
+ packages for configuration files that are not TeX input
+ files.
+ </p>
+ </sect>
In the section about hyphenation, I've added this:
+ <p>
+ Calling update-language is *not* sufficient to be able to
+ use the new hyphenation patterns; instead the formats that
+ use it need to be regenerated. This can be done by running
+ <tt>fmtutil-sys --byhyphen `kpsewhich --progname=latex
+ language.dat`</tt>.
+ </p>
+ <p>
+ If a package that provides additional hyphenation patterns
+ is removed, it must make sure the formats are properly
+ recreated without it. With the "magic comment" mechanism,
+ this means to run <prgn>update-language</prgn> and
+ <tt>fmtutil-sys --byhyphen `kpsewhich --progname=latex
+ language.dat`</tt> in <file>postrm</file>
+ </p>
+ <p>
+ There is currently no mechanism (i.e., no
+ <prgn>update-language</prgn>) for automatic addition of
+ hyphenation patterns to formats that do not use the same
+ hyphenation configuration file as LaTeX.
+ </p>
I tried to be as generic as possible, and not hardcode the pathname of
language.dat.
And finally, this is what Hilmar suggested, in the section on
update-fmtutil:
+ Upon package removal, <prgn>update-fmtutil</prgn> must be
+ called in postrm, and the created formats and log files
+ should be removed from the directory specified by
+ <tt>`kpsewhich -var-value=TEXMFSYSVAR`/web2c</tt>.
Comments welcome,
Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Reply to: