Description of problem: Scripts in question specify '--outputdir /usr/share/texmf/dvips/config'. This is plain wrong location as can be easily seen by running 'texconfig-sys' on a freshly installed system and looking under '== font map files == ' header. Moreover it applies possibly only to dvips and that is far from all what is required. Allowing updmap-sys to pick up its own output directories solves that nicely. 'texhash' run should not be limited to /usr/share/texmf as various files which needs to be looked upon may, and do, live elsewhere. Also %pre and %post scripts need to make sure that updmap.cfg is the one which is listed by 'texconfig-sys conf' on the original installation and which is marked as %config by rpm. Otherwise they create a new, independent, updmap.cfg in some directory which depends on changeable ordering in $TEXFONTMAPS variable. In other words a postinstall scriptlet should be like this: if [ "$1" = "2" ]; then [ -f /usr/share/texmf/dvips/config/tipa.map ] && \ rm -f /usr/share/texmf/dvips/config/tipa.map fi /usr/bin/texhash if [ "$1" = "1" ]; then /usr/bin/updmap-sys --cnffile /usr/share/texmf/web2c/updmap.cfg \ --quiet --nohash --enable Map=tipa.map fi and postuninstall one if [ "$1" = "0" ]; then /usr/bin/updmap-sys --cnffile /usr/share/texmf/web2c/updmap.cfg \ --quiet --nohash --disable tipa.map fi /usr/bin/texhash Version-Release number of selected component (if applicable): tetex-font-tipa-1.3-4 and it applies to FC4 as well. How reproducible: always and creating new updmap.sys is messing up a system as the first found updmap.sys is used so cleaning that up requires not only removing such extra configuration files and rerunnig, with a correct configuration file, updmap-sys for all extra packages with configuration written in a "wrong" places. Nasty and I do not see a good way to make that automatic.
Upon further reflection proposed changes are still wrong. A really used updmap.cfg file may indeed be somewhere in a tree searched by kpathsea and one may not to know really where for various reasons. Luckily this can be found out. Therefore these scripts should look like follows: if [ "$1" = "2" ]; then [ -f /usr/share/texmf/dvips/config/tipa.map ] && \ rm -f /usr/share/texmf/dvips/config/tipa.map fi /usr/bin/texhash cnffile="$(texconfig-sys conf | grep updmap.cfg)" if [ "$1" = "1" ]; then /usr/bin/updmap-sys --cnffile "$cnffile" \ --quiet --nohash --enable Map=tipa.map fi and cnffile="$(texconfig-sys conf | grep updmap.cfg)" if [ "$1" = "0" ]; then /usr/bin/updmap-sys --cnffile "$cnffile" --quiet --nohash --disable tipa.map fi /usr/bin/texhash One would hope that the above would be a default behaviour of updmap-sys but unfortunately, at least in the current incarnation, it is not.
Package is without maintainer and may be removed in the future if it keeps being unmaintained. If you have interest in this software, please consider becoming a Fedora Extras contributor: http://fedoraproject.org/wiki/Extras/Contributors [...] The wrong outputdir looks like it is left over from older versions of the package. That part is easy to fix. > 'texhash' run should not be limited to /usr/share/texmf > as various files which needs to be looked upon may, and > do, live elsewhere. The package doesn't do anything outside /usr/share/texmf, so only the ls-R database in /usr/share/texmf needs an update. > Also %pre and %post scripts need to make sure that updmap.cfg is > the one which is listed by 'texconfig-sys conf' on the original > installation and which is marked as %config by rpm. Otherwise > they create a new, independent, updmap.cfg in some directory > which depends on changeable ordering in $TEXFONTMAPS variable. updmap-sys defaults to loading /usr/share/texmf-config/web2c/updmap.cfg Trying to make the scripts work differently in a modified environment, where $TEXMFFOO variables are non-default doesn't sound like a good idea. > cnffile="$(texconfig-sys conf | grep updmap.cfg)" A grep like that would be too fragile. > always and creating new updmap.sys is messing up a system as the > first found updmap.sys is used I have no idea what this refers to.
> The wrong outputdir looks like it is left over from older versions > of the package. That part is easy to fix. Agreed on both counts. One of dangers of unnecessary hardwiring some assumptions. > The package doesn't do anything outside /usr/share/texmf, Not necessarily true. Even if the current tetex packaging does not explicitly include directories like /usr/share/texmf-var and /usr/share/texmf-config various actions create those, just because texmf.cnf say so and without any explicit user action, and freshly installed fonts may be legitimately interested what is there. Try to run on tetex-3.0 installation 'texconfig-sys conf' and see for yourself. Also a conclusion of discussions elsewhere was that most likely directories above will gain "an official package status" in the future and split of files between directories will change. Besides somebody may install fonts using, say, '--relocate' rpm option in an absolutely legitimate fashion. So the assumption "doesn't do anything outside ..." falls apart. > updmap-sys defaults to loading /usr/share/texmf-config/web2c/updmap.cfg No, not really. It defaults to _writing_ that one but it reads the first one found. Not the same thing and hence the issue. Try in the current distro rpm -qf /usr/share/texmf-config/web2c/updmap.cfg and see what you will get. You can find which one you are reading by looking at an output of 'texconfig-sys conf' and there is really no better method. > > cnffile="$(texconfig-sys conf | grep updmap.cfg)" > A grep like that would be too fragile. Oh, why? You will find that way only one file. The one _currently_ in use regardless of how one possibly reconfigured their system. Contrary to what you are saying the current method in simply in general not even fragile but plain broken. > I have no idea what this refers to. As I tried to explain in the current configuration 'updmap-sys' by default reads one file (on a "virgin" installation /usr/share/texmf/web2c/updmap.cfg which _is_ a part of the package) but it writes another one and you have no indication that you even can write there. The real breakage will come if some future update will change /usr/share/texmf/web2c/updmap.cfg while an installation of some package created some other configuration file which happens to take a precedence. Extra packages should NOT be doing such things like silently and automatically switching configuration files, especially that a user is allowed to locate that file somewhere else, and this is a serious package bug. I happen to think that the current default behaviour of 'updmap-sys', and 'fmtutil-sys', is really broken but one has to deal with that.
[running texhash] > Not necessarily true. Even if the current tetex packaging does not > explicitly include directories like /usr/share/texmf-var and > /usr/share/texmf-config various actions create those, just because > texmf.cnf say so and without any explicit user action, and freshly > installed fonts may be legitimately interested what is there. Doesn't convince me yet. Why update the other ls-R databases when no files change within those directories? > Besides somebody may install fonts using, say, '--relocate' rpm > option in an absolutely legitimate fashion. Illegal and unsupported. This package is _not_ relocatable. >>> cnffile="$(texconfig-sys conf | grep updmap.cfg)" >> >> A grep like that would be too fragile. > > Oh, why? You will find that way only one file. Roughly, there is no well-defined specifier, which ensures that the grep will not just grep an arbitrary line which contains "updmap.cfg". If at all, it should be something like: /usr/share/texmf/texconfig/tcfmgr --cmd find --file updmap.cfg
> Why update the other ls-R databases when > no files change within those directories? Because, contrary to what you may think, you may be changing "those directories" due to side-effects of those various configuration scripts. Let's see: $ texconfig-sys conf ............ ============================= font map files ============================= psfonts.map: /usr/share/texmf-var/fonts/map/dvips/updmap/psfonts.map pdftex.map: /usr/share/texmf-var/fonts/map/dvips/updmap/pdftex.map ps2pk.map: /usr/share/texmf-var/fonts/map/dvips/updmap/ps2pk.map dvipdfm.map: /usr/share/texmf-var/fonts/map/dvipdfm/updmap/dvipdfm.map ............ and also have a look at "kpathsea variables" below. It does not cost you anything significant in the whole process NOT to limit texhash run to specific directories and in return for missing "optimization" you know that you will not make mistakes no matter what. > Illegal and unsupported. This package is _not_ relocatable. Irrelevant. This was just some example. A particular installation may be configured in some ways you cannot predict. That exactly is what 'texmf.cnf' configuration file is for and changes there are always legal. Of course, somebody doing that has a better grasp on configuration issues then an average and likely can extricate her/himself from installation problems; but why make that necessary? The point is that if _they_ changed the way where used 'updmap.cfg' really resides then they are aware of that and it is their responsibility to ensure that the file is correct also in the future. If _you_ are silently changing that behind their back that is a bug. > grep will not just grep an arbitrary line which contains "updmap.cfg". There is no "arbitrary line". That is why it can be used. See how 'texconfig-sys' and kpathsea really work. If you have examples to the contrary I am all ears. But this grep was just a simple method to find with what configuration file we are really dealing. If you have alternative ways to ensure the same result, like a command you quote in the previous comment, and you feel more comfortable with those, then I am absolutely for it. This is just a small detail. If you think that in some situations you may get nothing from a search for 'updmap.cfg' (I do not think that this will be ever the case unless something is horribly broken with the whole setup but one may want to be prudent) then adding a check and action for this case is not something that complicated. A detail once again. [ "$cnffile" ] && /usr/bin/updmap-sys --cnffile "$cnffile" -quiet ... || \ /usr/bin/updmap-sys -quiet ...
[running texhash] > Because, contrary to what you may think, you may be changing "those > directories" due to side-effects of those various configuration scripts. kpathsee is only interested in added/removed files, not in changed files. > It does not cost you anything significant in the whole process NOT > to limit texhash run to specific directories and in return for missing > "optimization" you know that you will not make mistakes no matter what. This is the *only* pro-argument that counts. But anybody who wishes to maintain this package, may choose to apply this modification. > A particular installation may be configured in some ways you cannot > predict. And as I wrote before, I'm not going to try and make a package work in an unpredictable environment. If updmap-sys doesn't pick the right config file by default, that is a customisation bug and/or ought to be reported upstream. >> grep will not just grep an arbitrary line which contains "updmap.cfg". > > There is no "arbitrary line". That is why it can be used. ?? Well, take a look at the "texconfig" script and see how/where it looks for updmap.cfg. In comparison, FC3's older tetex doesn't do this, doesn't even come with texconfig-sys. IMO, doing this grep would be a hack and fragile.
> IMO, doing this grep would be a hack and fragile. Once again - I could not care less about grep. If you think that you have better ways to fix the current state, which is obviously broken, then do it differently and more power to you. This is not the issue. Moreover personally I am not interested at all in tipa fonts. Through many years of using TeX I did not need those (clearly this is not the case with others). I noticed the problem checking other things and what concerns me is that somebody may copy scripts in their innocence to another package and perpetuate the bugs.
Package has been without a maintainer for some time and has been removed from the Fedora Extras Development repository. It won't reappear unless somebody picks it up. For more information: http://fedoraproject.org/wiki/Extras/OrphanedPackages http://fedoraproject.org/wiki/Extras/FC5Status