From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020712
Description of problem:
while upgrading to latest Raw Hide, I got this error message:
159:XFree86 ########################################### [ 72%]
/var/tmp/rpm-tmp.96733: line 1: xftcache: command not found
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. remove the package containing xftcache (I don't know which that is yet :-)
2. upgrade XFree86 to 4.2.0-60.1
xftcache was a part of XFree86 in previous distribution releases.
It no longer exists anymore as it is replaced by fontconfig/fc-cache.
Whatever package is using xftcache in it's rpm scripts/triggers should
be using fc-cache instead. It isn't XFree86 though, so I'm reassigning
this to fontconfig.
rpm -q --triggeredby XFree86
seems to indicate the culprit is ttfonts. But ttfonts has been
removed from the distribution, so the we can't fix its triggers.
My best idea is to make something else obsolete ttfonts ... but
what? fontconfig? XFree86? urw-fonts?
Did the fonts completely go away or are they replaced by fonts from somewhere
else? We really don't want to obsolete them because then if people have a
specific reason to want them, we'll constantly be removing them.
They completely went away, because they were:
a) Awful fonts
b) Legally questionable (they were removed from OpenOffice.org CVS)
I suppose we could make fontconfig provide a symlink from
xftcache to fc-cache, but I really would hate to do this
because we would *never* be able to remove that xftcache symlink,
and it would just cause continuing confusion.
(Yet more evidence that "triggers suck")
I agree with Owen. We shoudn't have a symlink to xftcache IMHO,
as it could cause future problems. It would have bad assumptions
Personally, I think this problem can be closed as CANTFIX as it is
an rpm trigger problem, and as Owen says, triggers suck.
Too bad people are jumping to use triggers more and more to solve
*** Bug 71493 has been marked as a duplicate of this bug. ***
Since we can't fix ttfonts because the problem only occurs with an
already installed version and we can't change that, all we can do
is thrash anyone severely who adds triggers to rpm packages without
thoroughly testing them. ;o)
The xftcache symlink is a bad idea IMHO. Perhaps I should include
an xftcache shell script which does nothing.
interesting discussion. it seems to me that the problem is a missing dependency
in ttfonts (for "/usr/bin/xftcache"), not the trigger per se. with such a
dependency, apt-rpm would have suggested I remove ttfonts as upgrading XFree86
has higher priority. that's a moot point, though, since ttfonts can't be fixed.
another point is that care has to be taken when removing a package. in this
case, perhaps a new version sans triggers should have been shipped before removal.
anyway, I concur with the idea of a dummy shell script, at least through the 7.x
series. it should emit a warning about its obsoleteness, though, and perhaps
even name ttfonts as an obsolete package so that it is clear that it's not the
XFree86 RPM which is buggy.
another option is to make an RPM (compat-rh7x ?) with sundry compatibility
fixes, which amongst other things Conflicts: ttfonts.
Will you mark this as DEFERRED or WONTFIX?
Marking as WONTFIX
*** Bug 83722 has been marked as a duplicate of this bug. ***
Adding bug alias "xftcache" to report for ease in closing duplicate
bug reports that occur every time there is a new OS release or
XFree86 update, because the ttfonts trigger will essentially
cause this problem to happen forever. <sigh>
*** Bug 71402 has been marked as a duplicate of this bug. ***
*** Bug 78708 has been marked as a duplicate of this bug. ***