Bug 172535

Summary:	qalculate-gtk needs to depend on matching version of libqalculate
Product:	[Fedora] Fedora	Reporter:	Alex Lancaster <alex>
Component:	qalculate-gtk	Assignee:	Deji Akingunola <dakingun>
Status:	CLOSED NEXTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4	CC:	extras-qa
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-11-06 21:50:46 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alex Lancaster 2005-11-06 14:26:34 UTC

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):
qalculate-gtk-0.8.2-5.fc4

How reproducible:
Always

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 14:30:51 UTC

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 21:05:37 UTC

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.
Thanks.

Comment 3 Paul Howarth 2005-11-07 08:19:46 UTC

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 08:47:14 UTC

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 08:56:04 UTC

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 09:03:08 UTC

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 15:25:00 UTC

Got the messages Alex, I'll let upstream know about the issue.
Thanks all.