Red Hat Bugzilla – Bug 437014
xmltex should not have its own fmtutil.cnf fragment
Last modified: 2008-03-20 12:56:51 EDT
xmltex package brings its own fmtutil.cnf fragment, named xmltexfmtutil.cnf, containing two lines defining the xmltex and pdfxmltex formats. This is redundant, as the main fmtutil.cnf from texlive-texmf defines these formats. Moreover, it is buggy: recent releases of TeXlive use pdftex binary for latex.fmt and xmltexfmtutil.cnf does not reflect this change. I suggest to remove xmltexfmtutil.cnf from the distribution.
If the configuration file is planned to be removed, it has to be on the xmltex side.
I'm about to commit to xmltex/devel, as soon as I get access.
Stepan: Could you please specify what are you going to commit? Removal of .cnf file will cause troubles to passivetex build (as it expects xmltex cnf file on its old location) . I think the final conclusion we had with Jindrich was that the cnf file should be kept on xmltex side and only fmt files should be moved to /var/lib/texmf/web2c/... .
I thought that the xmltexfmtutil.cnf file might cause problem as it is not aware of the fact that latex in built on top of etex in recent versions of TeXlive. More generally, TeXlive changes from time to time, and the best option to keep compatible with the fashion-of-the-day is using the format definitions from TeXlives own fmtutil.cnf. If passivetex is not ready for the change, it shall be fixed too. As far as fmt files are concerned, xmltex should do what the main tex packages do. IIRC, it is: - do not build fmt during %build, - do not add them to the file database (even not as %ghost) which is what's usually done for most runtime generated files under /var - generate fmt files in %post scriptlets
Created attachment 298696 [details] change to spec I was about to commit these changes to spec file, together with cvs rm xmltexfmtutil.cnf.
Built as xmltex-20020625-11.fc9 (with required rebuild of passivetex and few other changes), closing RAWHIDE, hopefully it will not break anything.