On 10/11/05, Paul F. Johnson <paul@xxxxxxxxxxxxxxxxxxxxxx> 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 -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list