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.
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.
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.
(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.
(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.
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.
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.
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.
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.
I went ahead and committed the fix and kicked off a build for F-7. Can you do the builds for rawhide Peter?
Sure, Chris. Thanks for the proper fix. I'll push a rawhide build when I get home from work this evening.
This should be fixed already; closing as RESOLVED/RAWHIDE.