Bug 242318

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.