Bug 172507

Description of problem:
tetex-3 used in FC-4 and later uses different directories to store configuration
files and variables, namely /usr/share/texmf-config and /usr/share/texmf-var.

Moreover, the usage of these directories causes problems with updates and other
package additions.  Specifically, package tetex-font-cm-lgc from extras installs
an extra font and in the %post scriptlet calls the updmap-sys utility with the
"--enable Map cm-lgc.map" option to change the updmap.cfg file and then
translate it to psfonts.map, etc...

Calling updmap-sys without the --enable or --disable option does not alter
updmap.cfg, but uses the existing one, in /usr/share/texmf/web2c/updmap.cfg.
If the updmap-sys is called with the --enable option, a new updmap.cfg is
created and put in /usr/share/texmf-config/web2c/updmap.cfg.

From now on, two updmap.cfg files exist and only the second one is active (a
source of confusion).  Furthermore, the directory trees /usr/share/texmf-config
and /usr/share/texmf-var are not owned by any package and will be left behind
when tetex is removed.

There are two ways to fix this.  Either revert tetex behavior to use the same
tree for configuration and data files (/usr/share/texmf) or move the
configuration and variable files to the new locations (/usr/share/texmf-config
and /usr/share/texmf-var).

The most simple solution is the first one, but if sticking close to upstream is
more desirable, the second is the way to go.

Version-Release number of selected component (if applicable):
tetex-3.0-6.FC4

How reproducible:

Always.

Steps to Reproduce:

1.  Run updmap-sys with the --enable option (for example install tetex-font-cm-lgc)
2.  The newly created updmap.cfg is in /usr/share/texmf-config/web2c and its
translations (ps2pk.map, psfonts.map) in /usr/share/texmf-var.
3.  The old updmap.cfg, ps2pk.map, etc. are left stale in /usr/share/texmf, but
marked as %config in the spec file.  The new updmap.cfg, etc files are not
accounted for at all in rpm.
  
Actual results:


Expected results:


Additional info:

Please see also bug #172491 for another view on this.

A quick and dirty patch to keep all configuration files under /usr/share/texmf
follows

The problem is undoubtely real.  See bug 172491, bug 172492 and bug 172493
for nasty consequences.  Still I think that patch proposed in comment #1,
although undoubtely bit "safer", is not a real solution.  The problem is that it
modifies texmf.cnf, which is, and it is marked by rpm as, a configuration file
and everybody with an acces to it is  free to modify it any way deemed fit on
a particular installation.  Indeed, it exists exactly for those reasons.

Configuration files here are searched via kpathsea and they may reside in
various places.  Which one is _actually_ in use can be glimpsed from
'texconf-sys conf' output.  Configuration tools, and updmap-sys in particular,
definitely should not quietly modify a system configuration and this where
the real bug is hidden.

Luckily in the particular case of updmap-sys there are simple means to disarm
that bug.  Namely a config file to use can be found by this piece of a shell
code:
         cnffile="$(texconfig-sys conf | grep updmap.cfg)"

and with later updmap-sys operations one can use

         updmap-sys --cnffile "$cnffile" ....... 

to prevent creation of new config files in some "random" locations.

I cannot tell in this moment if similar dragons are lurking with other
tetex system config tools but the above shows that one has to be really careful
with their use.

I also agree with a suggestion that as long as texmf.cfg says
TEXMFSYSCONFIG = /usr/share/texmf-config
then in rpm packaging various config files should indeed move there.
That is likely a better long term solution than modifying TEXMFSYSCONFIG.
The fact that such move is possible should make one double careful in
writing scripts which can possibly use config tools in a write mode.

The patch cannot be used anyway as it patches texmf.cnf directly, what's not
right as it's generated from texmf.in-teTeX during compilation. So the proposed
patches intended to change default texmf configuration should patch this file
instead.

One cannot rely on a particular location of configuration files as it could be
reconfigured and "texconfig conf" or "texconfig-sys conf" is pretty easy to be
used for grepping out a location of a configuration file taken into account by
teTeX actually.

At least this bug showed me that:
1) texmf-config and texmf-var should be handled in spec and
2) some config files should be moved to tetex-config hierarchy.

Suggest to close this bug and open separate bug(s) for what's pointed out here
to avoid confusion and to track fixes and to go on with the discussion for the
proposed changes there.

> Suggest to close this bug and open separate bug(s) for what's pointed out here

All right, bug #172524.  Sounds reasonable to everybody?  This does not have
to be, of course, the last word. :-)

I will leave closing this bug to Sarantis as he opened it in the first place.

Will use suggestions in comment #3 to close dependent bug #172491 and #172492
(i.e. texconfig-sys conf output).

The other issues are covered I believe in bug #172524.
Closing this bug, as a duplicate of #172524.

*** This bug has been marked as a duplicate of 172524 ***