Hi,
Quite a few of the updates from today are giving me scriptlet errors as they're looking for /usr/bin/rebuild-gcj-db which doesn't exist. Should the package which provides this not have been dragged in from the rawhide yum update process?
Packages so far eclipse-ecj, libswt3-gtk2 (the update is only part way completed, so if there are more, I'll report them)
TTFN
Paul
On 10/11/05, Paul F. Johnson paul@all-the-johnsons.co.uk wrote:
Hi,
Quite a few of the updates from today are giving me scriptlet errors as they're looking for /usr/bin/rebuild-gcj-db which doesn't exist. Should the package which provides this not have been dragged in from the rawhide yum update process?
Packages so far eclipse-ecj, libswt3-gtk2 (the update is only part way completed, so if there are more, I'll report them)
This... is complicated. the /usr/bin/rebuild-gcj-db is controlled by the alternatives system. Which means no package actually "owns" that file location.. and in fact several different packages could in fact provide a version of that command. For example if you have sun's jre it should adequately provide this command..when managed via the alternatives system.
In terms of packages that are in Fedora..... java-1.4.2-gcj-compat-1.4.2.0-40jpp_51rh owns /usr/lib/jvm/jre-1.4.2-gcj/bin/rebuild-gcj-db which on a correctly setup alternatives system would be set up via a system of symlinks like /usr/bin/rebuild-gcj-db -> /etc/alternatives/rebuild-gcj-db /etc/alternatives/rebuild-gcj-db -> /usr/lib/jvm/jre-1.4.2-gcj/bin/rebuild-gcj-db
But the alternatives system abstracts file location.. I don't think there is a good solution to this problem. How do packages require a filelocation which could be provided by several "alternatives" ?
-jef