Bug 242318 - epiphany-extensions depends on exact firefox version
epiphany-extensions depends on exact firefox version
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: epiphany-extensions (Show other bugs)
7
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Peter Gordon
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-03 04:42 EDT by Frederik Hertzum
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-28 05:46:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Frederik Hertzum 2007-06-03 04:42:59 EDT
Description of problem:
epiphany-extensions is set to require firefox 2.0.0.3 exactly, resulting in it
being impossible to upgrade firefox beyond this point, without installing the
i386 firefox package.

Version-Release number of selected component (if applicable):
2.18.1
  
Additional info:
I have no idea if this is exclusive to x86_64, but I would consider it an odd
thing if the package specs where different and I therefor assume that the
problem is present on all platforms.
Comment 1 Peter Gordon 2007-06-03 15:29:01 EDT
The Error Viewer, Greasemonkey, Java Console, Live HTTP Headers, Page Info,
Smart Bookmarks, and various sample extensions all link to the libgtkembedmoz.so
and libxpcom.so shared libraries provided by Gecko/Firefox.

Unfortunately, the current system of Firefox packaging means that these
libraries are in a versioned directory such as /usr/lib/firefox-2.0.0.4/ (or
lib64, as the case may be). Thus, if there was no explicit requirement on a
Firefox version in the spec, then when a new firefox version is released the
dynamic linking breaks, and these extensions would fail to function properly or
have greater potential breakage. Thus, the explicit versioned Requires in the
spec file makes it so that this is caught immediately and prevents a user from
inadvertently upgrading Fx and breaking his install of epiphany-extensions. 

Come to think of it - Chris, could Firefox add its own path to the dynamic
linker configuration? A simple additional path in /etc/ld.so.conf.d/ with a call
to /sbin/ldconfig in the %post/%postun scriptlets would do it, methinks. That
would preclude the need for things being needed to be rebuilt against it, since
the linker would know to look in the versioned directory for libxpcom.so or
whatever shared library it needs to link against.

Thanks.
Comment 2 Frederik Hertzum 2007-06-04 06:17:02 EDT
epiphany.x86_64 should never poll firefox.i386 -- I can live with it being
dependent on a specific version of firefox, but since the x86_64 version of
epiphany can't use the i386 version of firefox, it should have the arch as part
of the requirements of firefox.
Comment 3 Christopher Aillon 2007-06-04 12:41:14 EDT
(In reply to comment #1)
> Come to think of it - Chris, could Firefox add its own path to the dynamic
> linker configuration? A simple additional path in /etc/ld.so.conf.d/ with a call
> to /sbin/ldconfig in the %post/%postun scriptlets would do it, methinks.

Except symbols change between releases so things compiled against version X will
now start to segfault against X+1.  Been there done that.  It's the reason why
packaging is the way it is.
Comment 4 Peter Gordon 2007-06-04 22:07:10 EDT
(In reply to comment #3)
> Except symbols change between releases so things compiled against version X will
> now start to segfault against X+1.  Been there done that.  It's the reason why
> packaging is the way it is.

Eep. Oh well; thanks for the clarification, Chris.

Frederik, I just tried this with the current epiphany-extensions (2.19.2 in
Development) on my x86_64 machine and a simple `yum install epiphany-extensions`
only pulls in firefox.x86_64 as a dependency (since its shared library
dependencies are marks as 64bit). Thus, it doesn't pull in the i386 version:

# yum install epiphany-extensions
[...]  
---> Package epiphany-extensions.x86_64 0:2.19.2-1 set to be updated
Matched firefox - 2.0.0.4-2.fc8.x86_64 to require for libxpcom.so()(64bit)
Matched firefox - 2.0.0.4-2.fc8.x86_64 to require for firefox
Matched firefox - 2.0.0.4-2.fc8.i386 to require for firefox
Matched firefox - 2.0.0.4-2.fc8.x86_64 to require for libgtkembedmoz.so()(64bit)
# of Deps = 3
--> Processing Dependency: libgtkembedmoz.so()(64bit) for package:
epiphany-extensions
Matched firefox - 2.0.0.4-2.fc8.x86_64 to require for libgtkembedmoz.so()(64bit)
TSINFO: Marking firefox - 2.0.0.4-2.fc8.x86_64 as install for epiphany-extensions
[...]

I'll therefore close this as NOTABUG; but if your issue persists, feel free to
reopen this with further details.

Thanks.
Comment 5 Frederik Hertzum 2007-06-05 15:24:32 EDT
I beg to differ.
Try this:
0: Make sure you have no firefox packages installed.
1: disable updates (to avoid install firefox 2.0.0.4) and install firefox.x86_64 
2: install epiphany and epiphany-extensions
3: update with updates enabled.

On my system this results in firefox-2.0.0.3.x86_64 being updated to
firefox-2.0.0.4.x86_64 AND to satisfy epiphany-extension dependencies,
firefox-2.0.0.3.i686 is being installed.

That the error is not visble in the current packages in the development repo
doesn't mean that the problem won't exist in future packages. Unless the spec
file fixes the problem with firefox.i686 satisifiying the dependecy for
epiphany-extensions.x86_64 it certainly IS a bug, even if it appears differently
with current packages in development.

I noticed that there is an update for epiphany and this makes problem even worse
-- epiphany depends on firefox-2.0.0.4 but extensions STILL depends on 2.0.0.3.

If you believe this has been fixed in a coming update, it should be marked as
NEXTRELEASE -- not NOTABUG.
Comment 6 Peter Gordon 2007-06-05 23:36:48 EDT
I just tried this in a entirely-default Fedora 7 x86_64 virtual machine (woo, go
KVM!) and - to my dismay - the current package does install both arches of
Firefox. However, the package in updates-testing installs only the x86_64
Firefox build.

Looking into it a bit deeper, I see that the version information in
epiphany-extensions means that the i386 2.0.0.3 will be installed to meet the
'firefox = 2.0.0.3' dependency, but the 2.0.0.4 x86_64 build is installed to
meet the 'libxpcom.so()(64bit)' and 'libgtkembedmoz.so()(64bit)' dependencies. 

However, with the updates-testing package, the 2.0.0.4 x86_64 Firefox build
matches BOTH the versioned 2.0.0.4 Firefox dependency _and_ the 64bit library
shared library dependencies. 

I'm mock-testing a new build which should fix this (making the firefox version
explicitly contain the target CPU information, such as 'firefox =
2.0.0.4.x86_64' et al.). When successful, I'll push it momentarily. In the mean
time, the package in the updates-testing repository should workaround this issue
with matching 2.0.0.4/x86_64 dependencies for both the version and shared
library requirements.

Thanks.
Comment 7 Peter Gordon 2007-06-06 00:34:44 EDT
Okay, 2.18.2-2 is in the queue for a push through updates-testing; but in the
meantime you can install the fixed packages directly from Koji (the build
system) if you wish:
http://koji.fedoraproject.org/packages/epiphany-extensions/2.18.2/2/

Does this new package build resolve the issue for you? Please let me know. Thanks.
Comment 8 Christopher Aillon 2007-06-06 01:22:11 EDT
GACK.  The reason this bug exists is because of the rpm querying happening in
the spec file.  Please do not call rpm -q in the specfile to determine what
versions you have.  That is broken.

Simply do the numbering normally.  Additionally, you ought to be requiring
gecko-libs/-devel.  This means you'll have to bump the number each time, but you
already have to touch the specfile, so it just takes an extra second.
Comment 9 Christopher Aillon 2007-06-06 01:33:51 EDT
I went ahead and committed the fix and kicked off a build for F-7.  Can you do
the builds for rawhide Peter?
Comment 10 Peter Gordon 2007-06-06 11:49:34 EDT
Sure, Chris. Thanks for the proper fix. I'll push a rawhide build when I get
home from work this evening.
Comment 11 Peter Gordon 2007-07-28 05:46:16 EDT
This should be fixed already; closing as RESOLVED/RAWHIDE.

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