Why can't my Fedora load find these files?

[John Collier]

I have been trying to do some updates and software loads on my little Fedora box and I have been running into pretty much the same messages time and time again.

(from mail LogWatch)

Unable to satisfy dependencies
Package openoffice.org-libs needs libICE.so.6, this is not available.
Package openoffice.org-libs needs libSM.so.6, this is not available.
Package openoffice.org-libs needs libX11.so.6, this is not available.
Package openoffice.org-libs needs libXext.so.6, this is not available.
Package openoffice.org needs libICE.so.6, this is not available.
Package openoffice.org needs libSM.so.6, this is not available.
Package openoffice.org needs libX11.so.6, this is not available.
Package openoffice.org needs libXaw.so.7, this is not available.
Package openoffice.org needs libXext.so.6, this is not available.
Package openoffice.org needs libXt.so.6, this is not available.
Package gaim needs libICE.so.6, this is not available.
Package gaim needs libSM.so.6, this is not available.
Package gaim needs libX11.so.6, this is not available.
Package gaim needs libXext.so.6, this is not available.

Now when I do a search for these files on my box, I can get the following results:

# find / -name *.so.6 -print
/usr/X11R6/lib/libICE.so.6
/usr/X11R6/lib/libSM.so.6
/usr/X11R6/lib/libX11.so.6
/usr/X11R6/lib/libXTrap.so.6
/usr/X11R6/lib/libXaw.so.6
/usr/X11R6/lib/libXext.so.6
/usr/X11R6/lib/libXi.so.6
/usr/X11R6/lib/libXmu.so.6
/usr/X11R6/lib/libXp.so.6
/usr/X11R6/lib/libXt.so.6
/usr/X11R6/lib/libXtst.so.6
/usr/X11R6/lib/libXaw3d.so.6
/usr/lib/libbeecrypt.so.6
/usr/lib/libfreetype.so.6
/lib/libc.so.6
/lib/libm.so.6

This tells me that the files are indeed there (I looked through the directories mentioned above and found the remaining files mentioned in the error messages as well).

I have seen this exact same type of message many times recently when I have tried to either update or install many different things and it is really starting to get under my skin!

Is there a path statement somewhere that isn't correct? Where would I look to get this issue resolved?

Doing a Google search for the keywords I can think of on this issue provide WAY too many results to be of any value to me, so you guys/gals are my last real hope...


Thanks,
John

[Martin P.J. Zinser · Accepted solution]

Hello John,

it looks like somehow your RPM database did not
notice that you installed a new version of X11 on your system and now thinks the libs are missing.

If you still have the Xfree RPM around, try the following

rpm -i -v --justdb

where file is the name of your Xfree RPM.

This should update the RPM database without actually performing any installation.

And just since I am paranoid, I would make a backup of my current RPM database before running this ;-)

Greetings, Martin

[John Collier]

Martin,

What if the packages that you install aren't from an RPM? I can't be sure of it right this moment, but I know that I have installed some stuff in the past that was either self-compiled or simply installed from the web based packages and it is possible that this package was one of them.

Is there a way to get around this?

[Stuart Browne]

Then if you're sure you've got the libraries, you'll just have to ignore dependancies whenever you want to install an X-based application that requires X-libs.

But what Martin is suggesting is that you grab the X RPM's from your install CD's, and force it to just do the RPM Database entries for them, to 'pretend' that you've installed your X using the RPM's. This will then satisfy the dependancy tree's in future install's.

[John Collier]

OK,

Two questions go with that idea then.

1: Won't the X RPMs from the install disks be somewhat different than the ones that were installed from the other sources?

2: If not, then would I just simply search the install disks for the RPM file in question and then point to it? (how would I know it when I saw it?)

What I was lead to believe was that most every configuration parameter in Linux was stored in a flat text-like file. If that is truly the case, then shouldn't it just be possible to 'massage' the correct file with the path information to 'correct' this location issue?

I hate to think that I will be forced to use nothing but RPM formatted installs for then entire life of my Linux box...

[Stuart Browne]

No, the RPM's are definately not flat-text, they are DBM's (from memory, DBM4 to be more exact).

Usually, if you start with RPM's, it's best to stick with RPM's.

Once you fall of the RPM path, maintenance becomes a headache as you have to remember what you have, and have not updated manually. The problem's you've run into is a by-product of not sticking to all-rpm's.

Now, that being said.. You've manually updated one of the major componants (X), alot of things depend upon beleiving the libraries are installed. As the RPM database doesn't think they are, it gets confused. What you can do however, is grab the X RPM's of your install CD's, and just do the database updates (as Martin suggested), thus fooling the system to beleive you've installed the X RPM's, and thus satisfying new RPM install's dependancy tree's.

[John Collier]

OK,

I have heard Martin's suggestion and I understand that Stuart supports this suggestion. This makes it a feasible option in my head.

The questions that I asked above ( #1 & #2) in my last post to this thread still apply to this situation.

The last thing I want to do is to muck things up even more by using the incorrect RPM information.

In my mind, if the RPM info from the Install media corresponded with the structure of the new package load, I wouldn't be having this issue right now. Of course, my mind has been proven to contain MANY flaws in it from time to time.

Is this one of those times? Can someone explain where my logic goes wrong on that?


Thanks again,
John

[Alexander Chuzhoy]

Sometimes in situations like this simply running "ldconfig" command helps.It configures dynamic linker run-time bindings.

[John Collier]

Alexander,

That suggestion seems a little easier than the other to someone like myself so I am willing to give it a try first.

One question though. Would you suggest simply running something like

ldconfig -v

or do you see one of the other options being better?

Maybe something along the lines of

ldconfig -vr root

What would you suggest?

[Stuart Browne]

'ldconfig' will update the 'ld.so' library caches.

RPM doesn't rely upon this for seeing if a given library is installed.

Now, as for questions #1&2..

The layout and content of the XFree86 RPM (the core of it at least) will have a copy of the same set of 'files' as the manually-installed version of X that you did. You can manually walk through and confirm this if you want by using 'rpm -qlp XFree86-.rpm' to get a list of the files (the '-p' means use package file, rather than the database).

By doing the '--justdb' thing, you're just telling the RPM database that those files are on the system, and making it beleive they are from the RPM.

It's a white-lie to the RPM database esentially. You know the files are there. You know they are good. RPM doesn't.