Bug 235009 - Update always breaks Galeon (libxpcom apps)
Summary: Update always breaks Galeon (libxpcom apps)
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Gecko Maintainer
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-04-03 09:17 UTC by Jan Kratochvil
Modified: 2018-04-11 08:56 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-12 11:05:28 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jan Kratochvil 2007-04-03 09:17:27 UTC
Description of problem:
After "firefox" gets updated "gecko" (od Fedora Extras) also needs to be updated
(Bug 230298) as there is "Requires: gecko-libs =".
But the binaries still work if one overrides the broken RPM dependencies.

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

How reproducible:

Steps to Reproduce:
1. yum update firefox

Actual results:
... would break dependencies

Expected results:
Clean update as firefox-1.5.0.x are all ABI compatible.

Additional info:
According to stransky the dependency is there for the direct
`/usr/lib64/firefox-' library reference.

IMO there should be specified an ABI stable release (1.5.0?), embedded this
version using `ld -soname libxpcom.so.1.5.0', provide
`/etc/ld.so.conf.d/firefox-' and the libxpcom applications need no
longer use any direct directories references as LDCONFIG should choose the most
recent version there according to comments:
   For example, if the two libraries libxy.so.1.1 and libxy.so.1.2
   exist and both have the same soname, e.g. libxy.so, a symbolic link
   is created from libxy.so.1.2 (the newer one) to libxy.so.
   libxy.so.1.2 and libxy.so are added to the cache - but not

Comment 1 Martin Stransky 2007-04-03 09:30:23 UTC
btw. this bug was filled after a short discussion here in Brno. 

Chris, why we use the /usr/lib/firefox-{version} directories what break the
update? Is there any security/ABI reason? Or did I miss something?

Comment 2 Jan Kratochvil 2007-04-03 09:36:58 UTC
Oops, forget about that `/etc/ld.so.conf.d/firefox-' note as I
expected multiple firefox version can get installed simultaneously which is not
possible anyway.

strasnky, I believe these directories were designed plugins for the unstable ABI
which makes sense for 1.5 vs. 2.0 but I just do not believe it is needed even
for the updates (.10).

On #brno you said Firefox is not absolutely ABI stable across its updates.  In
such case this whole Bug would become WONTFIX as its fix would require the RHEL
stable ABI backporting effort.

Comment 3 Denis Leroy 2007-04-03 12:45:23 UTC
Hopefully once the build systems are merged, we can setup some automated way of
doing this, or at least notify me ahead of time so i get a chance to push a
galeon update before the firefox RPMs are pushed...

Comment 4 Matěj Cepl 2007-04-03 14:42:42 UTC
Lace, did you mean that I should close this as WONTFIX?

Comment 5 Martin Stransky 2007-04-03 14:57:51 UTC
(In reply to comment #4)
> Lace, did you mean that I should close this as WONTFIX?

Please leave this bug open, I'll manage it. And I'd like to get a feedback from
Chris, at least.

Comment 6 Martin Stransky 2007-04-12 11:05:28 UTC
okay, closing.

Comment 7 Jan Kratochvil 2007-04-12 11:16:30 UTC
(In reply to comment #6)
> okay, closing.

Any reason why the incompatibility exists?

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