>>>>> benoit guillon <[EMAIL PROTECTED]> writes:
>>>> It would be nice to be able to use TEXINPUTS to override the
>>>> search path for TeX files as well. Unfortunately, dblatex
>>>> modifies TEXINPUTS so that its own files will take precedence
>>>> (unlike PYTHONPATH.)
>>> Actually, since the TeX files are in /usr/share/texmf (per Debian
>>> policy), no update_texinputs() invocation should be necessary.
>>> Perhaps, it could be commented out for the Debian package.
>> Intermediate summary of using dblatex files installed in parallel:
>> - Python: Use environment variable PYTHONPATH.
>> - TeX: Ivan's suggestion works, thus after patching Debian dblatex
>> to omit the superfluous manipulation of TEXINPUTS, use environment
>> variable TEXINPUTS.
>> - XSLT: As no environment variable is used here, dblatex would have
>> to be modified upstream. Benoît, are you willing to enhance dblatex
>> accordingly?
> There's something I don't understand: what the customization is for?
> In my opinion, there are two possible cases:
> - One wants to hack the package, for debug purpose, experiment it,
> and so on, with no maintenability in mind. In this case, he should
> start from the sourceforge tarball, since you can work as standalone
> with it, patch it, etc. with no interaction with system wide
> installed dblatex (the scripts/dblatex stub is provided for that).
It would make sense for a compiled package. However, for a
package which consists purely, or mostly, of interpreted files,
it's reasonable to start with a version that's included in the
distribution. That's how it works with, e. g., Emacs or
Lintian.
Furthermore, as one might want to work on several hacks in
parallel, starting from the tarball doesn't actually save one
from managing multiple versions of the tool. That's where
environment variables come to help:
$ FOODIR=~/my/hacks/foo-bar foo
$ export FOODIR=~/my/hacks/foo-baz
$ make # the build process uses foo
etc. (Instead of $ foo-bar and $ make FOO=foo-baz, and having
multiple directories where all the Foo files get installed.)
> - One wants to customize the installed package. In this case he
> should provide his own .sty, and require/include the default latex
> style files as needed. For the XSL part, he should provide his own
> XSL entry point (-p option), and override the necessary templates in
> it (that's one of the XSL strengths). The benefit is to separate
> clearly what is specific from what is not, and you can even manage
> the differences as an extension package.
It looks like a solution. Where I could read more about
overriding XSL templates?
It still would be nice if the default value for `-p' could be
supplied with an environment variable.
> Exploding the paths of the tool is somewhat dangerous: unconsistent
> XSL stylesheets vs latex stylesheets, etc. The only case where giving
> another xsldir can be interesting is for the debian packager, where
> the xsldir location differs from the default dblatex XSL location (no
> more need to have symbolic link). But for this particular case an
> environment variable is not suited, and I must thing about something
> else.
Agreed.
> In general, playing with multiple environment variables to override
> some stuff is not a good idea.
Originally I've suggested a single variable to override all the
stuff. Managing several variables requires extra care, but I
think it's acceptable.
