Red Hat Bugzilla – Bug 244487
gschem missing needed dependencies in rpm
Last modified: 2007-11-30 17:12:07 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:184.108.40.206) Gecko/20070603 Fedora/220.127.116.11-2.fc7 Firefox/18.104.22.168
Description of problem:
Clean install of F7 on X86_64 system. Installed geda-gschem and friends with graphical yum tool, but gschem bailed out when run with missing library messages.
To get gschem running, I had to install:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Install F7 clean.
2.Install geda-* tools from software update application, Applications/Engineering and Scientific
gschem failed to run with message:
gschem: error while loading shared libraries: libstroke.so.0: cannot open shared object file: No such file or directory
Installed libstroke by hand using yum. Run gschem again and get message:
gschem: error while loading shared libraries: libgeda.so.28: cannot open shared object file: No such file or directory.
Install libgeda by hand using yum, gschem runs properly.
geda-gschem package should specify libstroke and libgeda as dependency, yum should install packages to satisfy dependency.
Something is broken somewhere, because yum should pull those dependencies by
Can you give me the output of
rpm -qR geda-gschem
Was your installation successfully ?
Created attachment 157195 [details]
This is the log showing geda-gschem being installed on June 14. Libgeda was
not installed until June 15 when I installed in by hand.
Created attachment 157196 [details]
the output of rpm -qR geda-gschem
The output of rpm -qR geda-gschem shows libgeda and libstroke, so it is not
obvious why yum did not pull those two libraries in automatically.
I removed libgeda and libstroke using yum, and it correctly insisted on removing
all the geda-* packages because of dependencies. I re-installed geda-gschem
using yum, and it pulled in libstroke and libgeda like it should.
I have no idea why it failed the first time. Maybe I was pulling from an out of
date mirror or something.
Anyway, since the behavior can not be duplicated, this bug can be closed.