rawhide updates 11 Oct 2005

[Jeff Spaleta]

On 10/11/05, Paul F. Johnson <paul at 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