Bug 172493 - tetex-font-tipa - %pre and %post scripts totally out -to-lunch and actually harmful
tetex-font-tipa - %pre and %post scripts totally out -to-lunch and actually h...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: tetex-font-tipa (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Orphan Owner
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE6Target
  Show dependency treegraph
 
Reported: 2005-11-05 02:33 EST by Michal Jaegermann
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-21 08:31:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2005-11-05 02:33:40 EST
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.
Comment 1 Michal Jaegermann 2005-11-05 13:09:59 EST
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.
Comment 2 Michael Schwendt 2005-11-12 14:49:05 EST
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.
Comment 3 Michal Jaegermann 2005-11-12 17:50:26 EST
> 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.
Comment 4 Michael Schwendt 2005-11-13 05:05:57 EST
[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

Comment 5 Michal Jaegermann 2005-11-13 12:57:20 EST
> 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 ...
Comment 6 Michael Schwendt 2005-11-14 06:17:18 EST
[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.
Comment 7 Michal Jaegermann 2005-11-14 11:21:35 EST
> 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.
Comment 8 Michael Schwendt 2006-03-03 08:03:02 EST
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

Note You need to log in before you can comment on or make changes to this bug.