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): How reproducible: Always 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 3. Additional info:
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 at best. 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 problems. ;o(
*** 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. ***