Bug#64914: jadetex: doesn't update when language.dat is changed
reassign 64914 tetex-bin
retitle 64914 fmtutil has not extensibility mechanism
thanks
Julian Gilbey <J.D.Gilbey@qmw.ac.uk> writes:
> I've just noticed a problem. When language.dat is changed through
> texconfig, fmtutil --all is run. But as jadetex has its own
> fmtutil.cnf, texconfig doesn't notice.
Yup.
> The only obvious solution to this, which will be very useful if the
> tetex-bin package is split, is to have an /etc/texmf/fmtutil/
> directory with multiple .cnf files in, say base.cnf, pdf.cnf, jade.cnf
> and so on. Then fmtutil --all reads all of the files in the
> directory. I do not imagine that it will be that difficult to make
> the necessary modifications, although the search for the directory is
> not going to be trivial, it seems.
>
> The other way to do it is to modify fmtutil to start the run_initex
> function with:
>
> command -v "$engine" || return
>
> Then if a particular engine (such as jadetex) is not present, we just
> skip that format. And if we go for this option, then *all* formats
> get put in one master fmtutil.cnf (including jadetex). I don't know
> whether there are other tex format packages which call fmtutil in this
> way, but if not, this may be a good way forward.
> I'm happy to work on a patch for this, if necessary.
Well, please correspond to the tetex-bin maintainer. As the jadetex
maintainer, there's little I can really do to help in this matter.
fmtutil is provided in tetex-bin. It provides no extensibility
mechanism. This falls squarely under tetex-bin responsibility.
Without that facility, I can just do the best I can.
If the tetex-bin maintainer agrees, perhaps we could provide either a
modified fmtutil as you seem to be suggesting, or else (a better idea
IMHO) construct fmtutil.cnf from a buncha files which are catted
together, or else provide some way for me add lines to
'/etc/texmf/fmtutil.cnf' without breaking policy on config files of
other packages.
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: