Re: [DRAFT]: The Debian TeX Policy
Frank Küster <frank@debian.org> writes:
[ Debian TeX policy ]
> I have written it in debiandoc-sgml, and attach the source code as a
> file.
Is it not a little strange to write the TeX policy in anything other
than TeX? anyway...
> [1] Unfortunately there is no clear, abstract specification for the
> kpathsea library and the kpse`*' executables Packages should
> ensure
missing . [I can send you a patch for these typos things against the
sgml file, but I expect there's not much point at this early
stage---let me know what is best]
> 3. File Placement
> -----------------
>
> File locations must follow the TeX Directory Structure, TDS. It is a
> bug if a package does only conform to an outdated TDS version. It is
only conforms
> a more severe bug, however, it it conforms to the current TDS version
if it
> while the Basic TeX packages available or installed still do not
> support this version.
installed?
presumably you mean: the versions of the TDS supported by the Basic
TeX package and any other TeX package in any given Debian distribution
must agree?
> The following `TEXMF' trees can be used by packages, as outlined
> below, and must be searched for by any implementation of TeX and the
> kpathsea library:
>
> 1. `/usr/share/texmf/', referenced as TEXMFMAIN
>
> 2. `/var/lib/texmf/', referenced as VARTEXMF
>
> 3. `/usr/share/texmf-site/', referenced as SITETEXMF
>
> 4. `/usr/local/share/texmf/', referenced as TEXMFLOCAL
>
> 5. `$HOME/texmf/', referenced as HOMETEXMF
I don;t think it is a good idea to set the HOMETEXMF directory in
stone like this, as it should be up to the user. (I always change it
to $HOME/.texmf and I'm sure others disable $HOMETEXMF completely).
Maybe just say
5. Any directories listed in the $HOMETEXMF configuration option from
tetex.cnf,
Also, people should be allowed to override the texmf trees with
environment variables, or is that not going to be supported in future?
(I know that Debian Policy already says that packages are not to rely
on environmentals being set, but equally they should support them).
This is especially relevent to HOMETEXMF: I'm sure people on
comp.text.tex have been told to set $HOMETEXMF this way.
> 3.2. Filenames and installation of alternative files
> ----------------------------------------------------
>
> Packages may not install files with the same name as a file already
> installed in a TEXMF tree, unless both files are in subdirectories
> where they will only be found by different applications, as
> determinded by the `--progname' switch to kpsewhich.
>
> As an exception to this rule, packages that need newer versions of a
> file than already supplied by an other package and installed in
> TEXMFMAIN, can place them into SITETEXMF. The package must make sure
> that the newer version is backward-compatible, that is: It must not
> break compilation of any TeX document, and it should not change the
> output file. A change of the output file may be acceptable if an
> obviously buggy behavior is corrected, and if it had previously not
> been possible to systematically fix this behavior.
You need another exception here, otherwise If a user has the latest,
say, koma-script in HOMETEXMF or TEXMFLOCAL then the Basic TeX package
(which has an older koma-script) will not be allowed to install.
Maybe you meant to say "Packages may not install files which are
available from another package, even if the other package installs to
a different TEXMF tree"?
Also, what if two packages need a new version of some package (say
hyperef)? Is the idea that both *must* depend on a third package that
will install hyperref in SITETEXMF?
>
> Installing more than two versions of a file will most likely lead to
> confusion. Therefore, the possibility to shadow a file once using
> SITETEXMF should be enough, and the usage of `dpkg-divert' is
> discouraged.
>
> It is also discouraged to use a file other than from the canonical
> source for that file, usually the CTAN network.
> 4.1. Configuration update programs
> ----------------------------------
>
>
> Packages are free to add configuration items to the common
> configuration files, but they may not try to override configuration
> items that are yet supplied by other packages. Rather, shared
items that are already supplied by other packages
[A general comment on English here:
The opposite of "X is not yet Y" is (approximately) "X is already Y"
"X is yet Y" never makes sense, and always looks like a type for "X is
not yet Y" ;-)]
In fact here "they may not try to override configuration items that
are supplied by other packages" seems just as good
> configuration items must be supplied by the Basic TeX packages or any
> other package on which all involved packages depend, with a setting
> appropriate for all.
>
>
> 4.2. Best practices remark for packages that `build-depend' on the TeX
> system:
I think it makes just as much sense if you delete the word "remark" here
> might stop working after changed in the depended-on package, and such
changes
> 4.4. The Dpkg Post-Invoke Mechanism
> -----------------------------------
>
> To be done...
>
> Packages should be able to delay running of mktexlsr, updmap and
> perhaps even "fmtutil -all" until all TeX-related packages that want
> to do this are configured. Thus, it is unnecessary to call the
> programs multiple times. Coding this is easy, however it is unclear
> how it can be made sure that failures get attributed to the correct
> program (even updmap has recently been reported to fail).
If two packages request "fmtutil -all" to be run, and it fails, surely
there is no way to tell, since any change made by one could equally
have been made by the other. Maybe the exact error message will give
a clue to someone who Knows What They Are Doing, but for general users
(who know nothing of TeX)....
You could maybe say that each package that requires, say, mktexlsr, to
be run writes its name somewhere, and then somehow arrange it so that
when the user reports a bug the list of requesters is visible. That
way the tetex-base maintainers will have a (slightly) easier job
reassigning the bug to the correct place...
Reply to: