Bug 172535 - qalculate-gtk needs to depend on matching version of libqalculate
qalculate-gtk needs to depend on matching version of libqalculate
Product: Fedora
Classification: Fedora
Component: qalculate-gtk (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Deji Akingunola
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2005-11-06 09:26 EST by Alex Lancaster
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-11-06 16:50:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alex Lancaster 2005-11-06 09:26:34 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050923 Galeon/1.3.21

Description of problem:
qalculate-gtk-0.8.2-5.fc4 will not work against libqalculate-0.9.0-1.fc4 and will segfault if installed together.  It appears that the versions need to match and are not binary compatible across versions.  Unfortunately it appears that the implicit library dependencies generated by rpm aren't enough to ensure this because yum will happily install these packages together.

qalculate-gtk "requires" only libqalculate.so.0 and this dependency is satisfied by libqalculate-0.9.0-1.fc4 which "provides" the requested libqalculate.so.0. 

A stricter explicit requirement should be added to qalculate-gtk, e.g. in this case qalculate-gtk-0.8.2 should have this in the spec file:

Requires: libqalculate=0.8.2

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. yum upgrade
2. qalculate-gtk


Actual Results:  Segmentation fault

Expected Results:  qalculate-gtk should have run correctly

Additional info:

I worked around this problem by manually downgrading to the "matching" libqalculate-0.8.2-4.fc4.
Comment 1 Alex Lancaster 2005-11-06 09:30:51 EST
This happened because when I ran "yum upgrade" the repo just happened to be in a
state where the matching qalculate-gtk had not been rebuilt.  Nevertheless, the
spec file should be coded in such a way that even if non-matching pairs are
released to the repo, the requires will prevent the non-matching versions from
being incorrectly installed.
Comment 2 Deji Akingunola 2005-11-06 16:05:37 EST
I have requested a build of qalculate-gtk-0.9.0 that matches the current
libqalculate. But as you correctly noticed the other time, the build initially
failed because the build system was not fast enough in updating it repo
database.  In the future, I'll follow your advice and add an explicit dependence
on the appropriate version of libqualculate in the spec file.
The new build of qalculate-gtk-0.9.0 and qalculate-kde-0.9.0 should however
reach the mirror soon.
Comment 3 Paul Howarth 2005-11-07 03:19:46 EST
This sort of dependency should be handled by RPM's automatic library
dependencies, shouldn't it? If libqualculate has a change so significant that
the apps that use that library need rebuilding, shouldn't that have been
accompanied by a change in the soname of libqualculate?

Adding manual library version deps in packages seems very dubious to me.
Comment 4 Alex Lancaster 2005-11-07 03:47:14 EST
In theory, yes it should.  But it appears that upstream doesn't bump the .so up
to match and it appears that libqalculate/gtk-qalculate must be built as a pair,
because libqalculate-0.9.0 was not binary compatible with qalculate-gtk-0.8.2.  

This wouldn't be a problem if qalcuate-gtk and libqalcualate were built from the
same spec file/SRPM, but upstream doesn't do it that. So until this bug is fixed
upstream and/or the packages are built from the same spec file, the dependency
will need to be maintained manually.
Comment 5 Paul Howarth 2005-11-07 03:56:04 EST
Have you raised this issue upstream? That's where it needs fixing really. Adding
manual deps is only really a workaround.
Comment 6 Alex Lancaster 2005-11-07 04:03:08 EST
I am aware that it is only a workaround, but it until it is resolved upstream it
should be implemented manually, IMHO.  I was really just trying to bring this to
Deji's attention, since tracking/reporting bugs upstream really be the FE
packager's responsibility... ;-)
Comment 7 Deji Akingunola 2005-11-07 10:25:00 EST
Got the messages Alex, I'll let upstream know about the issue.
Thanks all.

Note You need to log in before you can comment on or make changes to this bug.