/usr/share/doc/tex-common/Debian-TeX-Policy.html/ch6.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">

<html>

<head>

<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">

<title>The Debian TeX sub-policy - Configuration</title>

<link href="index.html" rel="start">
<link href="ch5.html" rel="prev">
<link href="apA.html" rel="next">
<link href="index.html#contents" rel="contents">
<link href="index.html#copyright" rel="copyright">
<link href="ch1.html" rel="chapter" title="1 About this document">
<link href="ch2.html" rel="chapter" title="2 Terms and Definitions">
<link href="ch3.html" rel="chapter" title="3 TeX packages for the impatient">
<link href="ch4.html" rel="chapter" title="4 Meta-packages and dependencies">
<link href="ch5.html" rel="chapter" title="5 File Placement">
<link href="ch6.html" rel="chapter" title="6 Configuration">
<link href="apA.html" rel="appendix" title="A Sample code">
<link href="ch5.html#s-tds-libkpse" rel="section" title="5.1 File searching and libkpathsea / libkpse">
<link href="ch5.html#s5.2" rel="section" title="5.2 Directory trees">
<link href="ch5.html#s5.3" rel="section" title="5.3 Generated files">
<link href="ch5.html#s-sec-names-and-texmfsite" rel="section" title="5.4 Filenames and installation of alternative files">
<link href="ch5.html#s-sec-documentation" rel="section" title="5.5 Documentation">
<link href="ch6.html#s-configurationfiles" rel="section" title="6.1 Configuration files">
<link href="ch6.html#s-update-progs" rel="section" title="6.2 Configuration update programs">
<link href="ch6.html#s6.3" rel="section" title="6.3 Best practices for packages that build-depend on the TeX system">
<link href="ch6.html#s6.4" rel="section" title="6.4 Command execution and format files">
<link href="ch6.html#s6.5" rel="section" title="6.5 The Dpkg Post-Invoke Mechanism">
<link href="apA.html#s-appen-sample-font" rel="section" title="A.1 Sample code for font packages">
<link href="ch6.html#s-sec-font-configuration" rel="subsection" title="6.2.1 Font configuration">
<link href="ch6.html#s-font-configuration-details" rel="subsection" title="6.2.1.1 Description of manual font package setup">
<link href="ch6.html#s-font-configuration-rationale" rel="subsection" title="6.2.1.2 Rationale">
<link href="ch6.html#s6.2.2" rel="subsection" title="6.2.2 Language/Hyphenation configuration">
<link href="ch6.html#s6.2.3" rel="subsection" title="6.2.3 Format configuration">
<link href="ch6.html#s6.3.1" rel="subsection" title="6.3.1 Configuration">
<link href="ch6.html#s6.3.2" rel="subsection" title="6.3.2 Font cache data">

</head>

<body>

<p><a name="ch6"></a></p>
<hr>

<p>
[ <a href="ch5.html">previous</a> ]
[ <a href="index.html#contents">Contents</a> ]
[ <a href="ch1.html">1</a> ]
[ <a href="ch2.html">2</a> ]
[ <a href="ch3.html">3</a> ]
[ <a href="ch4.html">4</a> ]
[ <a href="ch5.html">5</a> ]
[ 6 ]
[ <a href="apA.html">A</a> ]
[ <a href="apA.html">next</a> ]
</p>

<hr>

<h1>
The Debian TeX sub-policy
<br>Chapter 6 - Configuration
</h1>

<hr>

<h2 id="s-configurationfiles">6.1 Configuration files</h2>

<p>
Files that are used to modify the behavior of executables must be treated as
any other configuration file in a Debian package.  However, files that are used
to control the typeset output - the appearance of documents - need not be
treated as configuration files.  It is up to the maintainer of the package to
decide which files make sense to be used for site-wide (as opposed to
per-project or per-document) customization.
</p>

<p>
A typical case for a site-wide configuration file is a file that must be
changed if a style file should use additional modules (installed, for example,
into TEXMFLOCAL).  Options that only control document output are rather used
for a particular document or documentation project and should usually not be
installed as a configuration file.
</p>

<p>
Note that <code>/etc/texmf/</code> is a usual TDS tree.  Files can be put into
appropriate TDS-conforming subdirectories (e.g.
<code>/etc/texmf/fonts/map/</code>), but directories not specified in TDS (or
added Debian-specifically in <code>tex-common</code>'s files in
<code>/etc/texmf/texmf.d/</code>) are generally not searched for TeX input
files and can be used by packages for configuration files that are not TeX
input files (e.g.  the files in subdirectories <code>fmt.d</code> or
<code>hyphen.d</code>).
</p>

<hr>

<h2 id="s-update-progs">6.2 Configuration update programs</h2>

<p>
Configuration files in the TeX world come in two classes: stackable and
unstackable.  The first class means that the respective programs read
<em>all</em> configuration files found, while in the later case only the top or
first configuration file is used.
</p>

<p>
Stackable configuration files in TeX are <code>TEXMFTREE/web2c/texmf.cnf</code>
(central configuration for TeX applications) and
<code>TEXMFTREE/web2c/updmap.cfg</code> (font configuration), while unstackable
configuration files are <code>TEXMFTREE/tex/generic/config/language.dat</code>
(language support/hyphenation patterns for latex based formats),
<code>TEXMFTREE/tex/generic/config/language.def</code> (the same for etex based
formats), <code>TEXMFTREE/tex/generic/config/language.dat.lua</code> (the same
for luatex based formats), and <code>TEXMFTREE/web2c/fmtutil.cnf</code> (for
format definitions).
</p>

<p>
In Debian, by default the respective configuration files of the following trees
are used: For <code>texmf.cnf</code>: TEXMFDEBIAN (the texmf.cnf file is a link
to the one in TEXMFMAIN).  For <code>updmap.cfg</code>:TEXMFDIST, TEXMFDEBIAN.
For the unstackable configuration files the respective copies in TEXMFSYSVAR
are used.
</p>

<p>
The stackable configuration files are either static (texmf.cnf) or generated
automatically in the background without any need for configuration, since
changes can be included in a higher order configuration file.
</p>

<p>
The non stackable configuration files plus the file
<code>/etc/texmf/web2c/texmf.cnf</code> are generated by configuration update
programs from configuration files in subdirectories of <code>/etc/texmf</code>.
For all of them this is the only method of configuration.
</p>

<p>
Packages are free to add configuration items to the common configuration files,
but they should not try to override configuration items that are supplied by
other packages.  Rather, shared configuration items should be supplied by the
Basic TeX packages or any other package on which all involved packages depend,
with a setting appropriate for all.  If this is impractical, the involved
packages must at least agree on the way different packages override other's
settings[<a href="footnotes.html#f5" name="fr5">5</a>].
</p>

<p>
The configuration update programs should be called without any options to allow
for internal changes, e.g.  of the directories where the generated files are
placed.
</p>

<p>
Packages that changed <code>updmap.cfg</code> must call <code>updmap-sys</code>
as detailed in <a href="#s-sec-font-configuration">Font configuration, Section
6.2.1</a>.  Packages that changed <code>language.dat</code> or
<code>fmtutil.cnf</code> must call <code>fmtutil-sys</code> (see below).  They
must make sure to issue the <code>mktexlsr</code> command before this.
</p>

<hr>

<h3 id="s-sec-font-configuration">6.2.1 Font configuration</h3>

<p>
A package that provides PostScript Type&nbsp;1 fonts for TeX should be usable
with any Basic TeX Package.  The recommended way to implement the configuration
scheme described below is to use the <code>debhelper</code> program
<code>dh_installtex</code> provided by <code>tex-common</code>.  See
<code>dh_installtex(1)</code> for usage details.
</p>

<hr>

<h4 id="s-font-configuration-details">6.2.1.1 Description of manual font package setup</h4>

<p>
This section describes how <code>dh_installtex</code> manages font packages,
and what packages need to do that want to do without it.
</p>

<p>
For the rest of this section, we'll assume we are dealing with a package named
<var>package</var> that installs PostScript Type&nbsp;1 fonts for TeX.
<var>package</var> should fulfill the following requirements:
</p>
<ol type="1" start="1" >
<li>
<p>
It should depend on <code>tex-common</code> but not on any Basic TeX Package,
unless needed for another task than simply installing the fonts for TeX.
</p>
</li>
</ol>
<ol type="1" start="2" >
<li>
<p>
It should install the necessary map files (<code>.map</code> extension) below
<code><var>TEXMFMAIN</var>/fonts/map</code>.  The precise location must conform
to the applicable TDS version.
</p>
</li>
</ol>
<ol type="1" start="3" >
<li>
<p>
It should also obviously install other needed or useful files provided by
upstream to use the fonts with TeX-related programs (<code>.pfb</code>,
<code>.tfm</code>, <code>.enc</code>, <code>.fd</code>, <code>.sty</code>,
documentation, etc.).
</p>
</li>
</ol>
<ol type="1" start="4" >
<li>
<p>
It should install one or more configuration files with names following the
pattern <samp>20<var>name</var>.cfg</samp> into
<code>/etc/texmf/updmap.d/</code>[<a href="footnotes.html#f6"
name="fr6">6</a>].  Such files will be later merged by
<code>update-updmap</code> to form
<code>/var/lib/texmf/web2c/updmap.cfg</code>, the effective configuration file
for <code>updmap-sys</code>.
</p>

<p>
Exactly what to put in these files is documented in
<code>update-updmap(1)</code>.  Basically, they should contain the
pseudo-comment:
</p>

<pre>
     # -_- DebPkgProvidedMaps -_-
</pre>

<p>
as well as the usual <samp>Map</samp> and/or <samp>MixedMap</samp> lines that
<var>package</var> needs to add to
<code>/var/lib/texmf/web2c/updmap.cfg</code>.
</p>
</li>
</ol>
<ol type="1" start="5" >
<li>
<p>
It should install a file named
<code>/var/lib/tex-common/fontmap-cfg/<var>package</var>.list</code> that
contains a reference to every <samp>.cfg</samp> file from the previous step,
one per line.  For instance, if <var>package</var> installs
<code>20foo.cfg</code> and <code>20bar.cfg</code> into
<code>/etc/texmf/updmap.d/</code>, the contents of
<code>/var/lib/tex-common/fontmap-cfg/<var>package</var>.list</code> should be:
</p>

<pre>
     20foo
     20bar
</pre>

<p>
This <code><var>package</var>.list</code> file must be shipped in the
<samp>.deb</samp>, so that when <var>package</var> is removed (not necessarily
purged), <code><var>package</var>.list</code> disappears from
<code>/var/lib/tex-common/fontmap-cfg/</code>.
</p>
</li>
</ol>
<ol type="1" start="6" >
<li>
<p>
It should run:
</p>
<ul>
<li>
<p>
in <code><var>package</var>.postinst</code>;
</p>
</li>
<li>
<p>
when <code><var>package</var>.postrm</code> is called with <samp>remove</samp>
or <samp>disappear</samp> as its first argument
</p>
</li>
</ul>

<p>
the following commands in this order: <samp>update-updmap --quiet</samp>,
<samp>mktexlsr</samp> and <samp>updmap-sys</samp>.
</p>

<p>
Since <code>mktexlsr</code> and <code>updmap-sys</code> are provided by the
Basic TeX Packages, <code><var>package</var>.postinst</code> has to ensure that
they are only called when found in <samp>$PATH</samp> (unless
<var>package</var> depends on the Basic TeX Packages for some reason).  In
<code><var>package</var>.postrm</code>, the same considerations must be taken
into account, with the addition that <code>tex-common</code> (that provides
<code>update-updmap</code>) can be unconfigured or even uninstalled.
</p>

<p>
Note that even when <code>tex-common</code> is configured, it cannot be assumed
that <code>update-updmap</code>, <code>mktexlsr</code> and
<code>updmap-sys</code> can be safely run whenever available, because they
internally use <code>kpsewhich</code> which only works after the
<code>libkpathsea</code> library in a separate package has been configured
properly.[<a href="footnotes.html#f7" name="fr7">7</a>] The following check can
be used to determine whether <code>libkpathsea</code> is configured:
</p>

<pre>
     if kpsewhich --version &gt;/dev/null 2&gt;&amp;1; then
         echo &quot;kpsewhich is installed and libkpathsea is configured.&quot;
     else
         echo &quot;Either kpsewhich is not installed, or libkpathsea is not configured.&quot;
     fi
</pre>
</li>
</ol>

<p>
A sample implementation of this scheme can be found in <a
href="apA.html#s-appen-sample-font">Sample code for font packages, Section
A.1</a>, but the recommended way to implement this scheme is to use
<code>dh_installtex</code>.
</p>

<hr>

<h4 id="s-font-configuration-rationale">6.2.1.2 Rationale</h4>

<p>
The rest of this section explains the rationale behind the previous
recommendations.
</p>
<ul>
<li>
<p>
The dependency on <code>tex-common</code> ensures that in
<code><var>package</var>.postinst</code>, <code>update-updmap</code> can be run
and <code>texmf.cnf</code> is in a sane state, so that <code>mktexlsr</code>
and <code>updmap-sys</code> can be run safely (if present and if
<code>libkpathsea</code> is configured).
</p>
</li>
</ul>
<ul>
<li>
<p>
The recommended order for running the programs <code>update-updmap</code>,
<code>mktexlsr</code> and <code>updmap-sys</code> ensures that
<code>updmap-sys</code> can locate the newly-installed files (in particular,
the map files shipped by <var>package</var>), since <code>mktexlsr</code> is
run before <code>updmap-sys</code>.  It is also run after
<code>update-updmap</code>, because
<code>/var/lib/texmf/web2c/updmap.cfg</code> might have been created by
<code>update-updmap</code>, although it more probably already existed.  And
since it would be of no use to call <code>mktexlsr</code> before
<code>update-updmap</code>, we recommend to run it after, just in case.
</p>
</li>
</ul>
<ul>
<li>
<p>
Now, about the &quot;magic comments&quot; in
<code>/etc/texmf/updmap.d/*.cfg</code> and the
<code><var>package</var>.list</code> file in
<code>/var/lib/tex-common/fontmap-cfg/</code>.  When that <var>package</var> is
removed, but not purged, it has to make sure that its
<code>update-updmap</code> configuration files in
<code>/etc/texmf/updmap.d/</code> are ignored.  Otherwise, any call to
<code>updmap-sys</code> by an other package or the local admin would fail
because it cannot find <var>package</var>'s map files.  Besides, we want the
<code>/etc/texmf/updmap.d/*.cfg</code> files to be conffiles (unless we really
have no other choice), because then <code>dpkg</code> automatically handles
upgrades while preserving user modifications for them.  As a consequence,
moving the <code>.cfg</code> files from <var>package</var> out of the way when
it is removed is not an option.  Moreover, the user would wonder where his
configuration files have gone in such a case.
</p>

<p>
The solution we chose was to add a little bit of logic into
<code>update-updmap</code>, so that whenever it sees a <code>.cfg</code> file
(let's call it <code>20foo.cfg</code>) that has the &quot;magic comment&quot;,
it actually includes its contents into <code>updmap.cfg</code> if, and only if:
</p>
<ul>
<li>
<p>
it is up-to-date (which is assumed if <code>20foo.cfg.dpkg-new</code> doesn't
exist in the same directory);
</p>
</li>
</ul>
<ul>
<li>
<p>
<samp>20foo</samp> appears on a line by itself in one of the <code>.list</code>
files in <code>/var/lib/tex-common/fontmap-cfg/</code>.
</p>
</li>
</ul>

<p>
Additionally, that <code>.list</code> file should be named
<code><var>package</var>.list</code> if <code>20foo.cfg</code> comes from
<var>package</var>, for simple reasons of tidiness.
</p>

<p>
With this little mechanism in place, all the rest follows as expected:
</p>
<ul>
<li>
<p>
When <var>package</var> is removed, but not purged,
<code><var>package</var>.list</code> is first removed by <code>dpkg</code> from
<code>/var/lib/tex-common/fontmap-cfg/</code>, thus disabling the the
<code>.cfg</code> files shipped by <var>package</var> as far as
<code>update-updmap</code> is concerned.  Then,
<code><var>package</var>.postrm</code> calls <code>update-updmap</code>,
<code>mktexlsr</code> and <code>updmap-sys</code>, with the result that
<var>package</var>'s map files aren't listed anymore in the final map files
(<code>psfonts.map</code>, <code>pdftex.map</code>...) generated by
<code>updmap-sys</code>.
</p>
</li>
</ul>
<ul>
<li>
<p>
If <var>package</var> is reinstalled later, two files are first created by
<code>dpkg</code> during the unpack phase:
<code>/var/lib/tex-common/fontmap-cfg/<var>package</var>.list</code> and
<code>/etc/texmf/updmap.d/20foo.cfg.dpkg-new</code>.  As long as the second one
exists, the conffile <code>/etc/texmf/updmap.d/20foo.cfg</code> will be ignored
by <code>update-updmap</code>[<a href="footnotes.html#f8" name="fr8">8</a>]
because it may be outdated.  Eventually, <var>package</var> is configured;
<code><var>package</var>.postinst</code> runs <code>update-updmap</code>,
<code>mktexlsr</code> and <code>updmap-sys</code>, and the <code>.cfg</code>
files shipped by <var>package</var> aren't ignored by
<code>update-updmap</code> this time, since they are referenced in
<code>/var/lib/tex-common/fontmap-cfg/<var>package</var>.list</code> and the
<code>.dpkg-new</code> files don't exist anymore.  Thus, the map files shipped
by <var>package</var> do end up in the final map files generated by
<code>updmap-sys</code>.
</p>
</li>
</ul>
</li>
</ul>

<hr>

<h3 id="s6.2.2">6.2.2 Language/Hyphenation configuration</h3>

<p>
A package that provides additional hyphenation patterns for TeX should be
usable with any Basic TeX Package.  The recommended way to implement the
configuration scheme described below is to use the <code>debhelper</code>
program <code>dh_installtex</code> provided by <code>tex-common</code>.  See
<code>dh_installtex(1)</code> for usage details.  Note that for
<code>language.dat</code>, order is important: english should always be the
first language.
</p>

<p>
These packages should put the actual hyphenation file into the respective
places in <var>TEXMFMAIN</var>, and have them registered by putting a
configuration file with extension <samp>.cnf</samp> into
<code>/etc/texmf/language.d</code> and calling <samp>update-language</samp>.
The file contents will then be incorporated into
<code>/var/lib/texmf/tex/generic/config/language.dat</code>, the effective
configuration file for TeX and friends' hyphenations.
</p>

<p>
Hyphenation patterns present the same problem as described in the previous
section for font configuration files: If the package is removed, but not
purged, the patterns are deleted, but the configuration information is still in
<code>/etc/texmf/language.d/</code>, and the format generation would fail if
they would be included in <code>language.dat</code>.  Therefore, an analogous
mechanism has been implemented as described for <code>update-updmap</code>: If
a file in <code>/etc/texmf/language.d/</code> contains the &quot;magic
comment&quot;
</p>

<pre>
     # -_- DebPkgProvidedMaps -_-
</pre>

<p>
it will only be used as long it is:
</p>
<ul>
<li>
<p>
up-to-date (which is assumed if the same file with <code>.dpkg-new</code>
suffix doesn't exist in the same directory);
</p>
</li>
</ul>
<ul>
<li>
<p>
listed in a file in <code>/var/lib/tex-common/language-cnf/</code> which should
have the name <code><var>package</var>.list</code>.
</p>
</li>
</ul>

<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 <samp>fmtutil-sys --byhyphen `kpsewhich
--progname=latex language.dat`</samp>.
</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 &quot;magic
comment&quot; mechanism, this means to run <code>update-language</code> and
<samp>fmtutil-sys --byhyphen `kpsewhich --progname=latex language.dat`</samp>
in <code>postrm</code>
</p>

<p>
There is currently no mechanism (i.e., no <code>update-language</code>) for
automatic addition of hyphenation patterns to formats that do not use the same
hyphenation configuration file as LaTeX.
</p>

<p>
The recommended way for implementing this scheme is to use
<code>dh_installtex</code>.
</p>

<hr>

<h3 id="s6.2.3">6.2.3 Format configuration</h3>

<p>
As with font map configuration and language hyphenation patterns configuration,
packages that provide additional formats should be usable with any Basic TeX
Package.  The recommended way to implement the configuration scheme described
below is to use the <code>debhelper</code> program <code>dh_installtex</code>
provided by <code>tex-common</code>.  See <code>dh_installtex(1)</code> for
usage details.  Note that for <code>fmtutil.cnf</code>, order is important:
Formats will be created for each line, and thus format files created from later
lines will overwrite earlier ones.
</p>

<p>
These packages should put a configuration file according to
<code>fmtutil.cnf(5)</code> into <code>/etc/texmf/fmt.d/</code>, run
<code>update-fmtutil</code> and subsequently create the format with
<samp>fmtutil-sys --byfmt <var>format</var></samp>.  <code>fmtutil-sys</code>
will only try to create the format if it can find the corresponding
<code><var>format</var>.ini</code> file (the last argument in an
<code>fmtutil.cnf</code> line).  Therefore the
<code><var>format</var>.ini</code> file should not be a conffile.
</p>

<p>
If a package needs to create formats at runtime, it should use a local
<code>fmtutil.cnf</code> with the appropriate entries and specifiy its location
to <code>fmtutil</code> on the command line, using the <samp>--cnffile</samp>
switch.
</p>

<p>
Upon package removal, <code>update-fmtutil</code> must be called in postrm, and
the created formats and log files should be removed from the directory
specified by <samp>`kpsewhich -var-value=TEXMFSYSVAR`/web2c</samp>.
</p>

<p>
The recommended way for implementing this scheme is to use
<code>dh_installtex</code>.
</p>

<hr>

<h2 id="s6.3">6.3 Best practices for packages that <samp>build-depend</samp> on the TeX system</h2>

<hr>

<h3 id="s6.3.1">6.3.1 Configuration</h3>

<p>
If packages that build-depend on the TeX system need a changed configuration,
they should not try to provide it statically.  If settings in any other
configuration file are inappropriate for a package to build, this is (usually)
a bug in the package that provides the file.  It should be fixed in this
package, not circumvented by a workaround in the build process.  Such
workarounds have proven to be problematic, because they might stop working
after changes in the depended-on package, and such failure cannot be foreseen
by its maintainers.  If a change is still necessary, the package should use the
configuration update programs with the <samp>--outputdir</samp> and
<samp>--add-file</samp> options.
</p>

<hr>

<h3 id="s6.3.2">6.3.2 Font cache data</h3>

<p>
Font cache data are created each time a font in Metafont format is used, and
placed by default in <var>TEXMFVAR</var>.  During package build, this has to be
avoided.  In order to be able to clean up the generated files (and only those),
the font cache should instead be put below the build directory.  This can be
achieved by setting <var>TEXMFVAR</var> to a subdirectory of the current
directory, e.g.  <code><var>$(CURDIR)</var>/.texmf-var</code>, using Make's
built-in variable.  Packages which do not change <var>TEXMFVAR</var>
<em>must</em> not create documentation that uses Metafont fonts in the
<samp>binary</samp> target.
</p>

<hr>

<h2 id="s6.4">6.4 Command execution and format files</h2>

<p>
If TeX formats need to be generated before execution, this should be done in
the post-installation script.  Packages that depend on an executable can thus
simply declare <samp>Depends:</samp> on the package providing the executable,
and <em>only</em> do that.  Any additional checks, e.g.  for the existence of
format files, is unnecessary and harmful, causing internal changes (e.g.  of
format file extensions) to break the depending package that does this check.
Maintainer scripts or programs in Debian packages should always use
<code>fmtutil</code> or <code>fmtutil-sys</code> for format generation, and
either add a <code>fmtutil.cnf</code> snippet in <code>/etc/texmf/fmt.d/</code>
(with <code>fmtutil-sys</code>, for site-wide formats), or use
<code>fmtutil</code> with the <samp>--cnffile</samp> option and an appropriate
local <code>fmtutil.cnf</code> (for runtime programs)
</p>

<p>
Local administrators can override settings from <code>texmf.cnf</code> with
environment variables; this has sometimes lead to errors in
<code>postinst</code> scripts.  It is recommended that <code>postinst</code>
scripts unset relevant variables before format creation or other problematic
tasks.
</p>

<p>
If an add-on package generates a format upon installation that needs a base
format (e.g.  latex.fmt), it must not load the existing base format [<a
href="footnotes.html#f9" name="fr9">9</a>].  Instead the
<code>fmtutil.cnf</code> snippet and the <code><var>format</var>.ini</code>
file must be changed so that the process of format creation is repeated.  For
example, if upstream creates their format by loading latex:
</p>

<pre>
     latex           pdfetex         language.dat    -translate-file=cp227.tcx *latex.ini
     jadetex         etex            language.dat    &amp;latex jadetex.ini
</pre>

<p>
and the following <code>jadetex.ini</code> file:
</p>

<pre>
     \input jadetex.ltx
     \dump
</pre>

<p>
then the Debian package maintainer must load <code>latex.ini</code> instead of
<code>latex.fmt</code>, making sure that <samp>\dump</samp> in
<code>latex.ltx</code> has no effect, and create the following new
<code>jadetex.ini</code>:
</p>

<pre>
     \let\savedump\dump
     \let\dump\relax
     \input latex.ini
     \let\dump\savedump
     
     \input jadetex.ltx
     \dump
</pre>

<p>
and the following snippet for <code>fmtutil.cnf</code>:
</p>

<pre>
     jadetex         etex    language.dat    -translate-file=cp227.tcx *jadetex.ini
</pre>

<hr>

<h2 id="s6.5">6.5 The Dpkg Post-Invoke Mechanism</h2>

<p>
This section was intended to deal with a once-planned mechanism that would
allow to delay running of mktexlsr, updmap and perhaps even &quot;fmtutil
--all&quot; until all TeX-related packages that want to do this are configured.
Thus, it would be unnecessary to call the programs multiple times.  Coding this
is not hard, however it is unclear how it could be made sure that failures get
attributed to the correct package.  Therefore this plan has been dropped.
</p>

<hr>

<p>
[ <a href="ch5.html">previous</a> ]
[ <a href="index.html#contents">Contents</a> ]
[ <a href="ch1.html">1</a> ]
[ <a href="ch2.html">2</a> ]
[ <a href="ch3.html">3</a> ]
[ <a href="ch4.html">4</a> ]
[ <a href="ch5.html">5</a> ]
[ 6 ]
[ <a href="apA.html">A</a> ]
[ <a href="apA.html">next</a> ]
</p>

<hr>

<p>
The Debian TeX sub-policy
</p>

<address>
generated from $Id$<br>
<br>
The Debian TeX mailing list <code><a href="mailto:debian-tex-maint@lists.debian.org">mailto:debian-tex-maint@lists.debian.org</a></code><br>
<br>
</address>
<hr>

</body>

</html>
tex-common 4.04 / usr / share / doc / tex-common / Debian-TeX-Policy.html / ch6.html
