Red Hat Bugzilla – Bug 134455
Firefox should provide libxpcom.so ???
Last modified: 2007-11-30 17:10:50 EST
Description of problem: In order to install firefox-0.10.1-1.0PR1.8 I needed first to remove several non-Fedora packages, including liferea and mplayerplug-in. This was because mozilla/firefox/thunderbird all normally seem to provide libxpcom.so but it has been removed from the newest firefox release. Seems like a mistake to have removed it if remains in all the others still. Having to install mozilla on top of firefox kind of defeats the point of firefox. Version-Release number of selected component (if applicable): firefox-0.10.1-1.0PR1.8 How reproducible: Always Steps to Reproduce: 1.Try to install (upgrade) newest firefox package over prior installation that also uses mplayerplug-in. 2. 3. Actual results: Dependency issues tied back to libxpcom.so, which is present in prior firefox packages, and all(?) other mozilla and thunderbird packages. Expected results: Should not break dependences from prior versions. Additional info:
Bill, is this related to your change that you made?
Yes. OK, so the problem is: - firefox, mozilla, and thunderbird all provide libxpcom.so. This wreaks havoc on dependency solvers, in that any time a package requires libxpcom.so, the dependency solver has to try and guess which app the user really needs. To eliminate this problem, the provides were removed from firefox and thunderbird, as all the apps that are linking against mozilla libraries in FC3 are linking against the ones provided by 'mozilla'. (Evolution and Epiphany, to be precise.) Now, the question is: a) were liferea and mplayer-plugin built against firefox? (Assumed answer: no) b) how much can we presume that apps built against mozilla work against firefox? c) how do we structure this to avoid the dependnency problems mentioned above?
Can you define a "common" package of pieces that firefox/thunderbird/mozilla all (redundently) use and make that package (mozilla-common) a depends for firefox/thunderbird/mozilla (and also any package that depends on one of those)? If the answer is a simple no, you don't need to explain why here. I'll understand more of this eventually.
Splitting the common core is a long distant goal, but it wont happen until probably FC5 timeframe, and only if someone actually works on it.
No, you can't really define a common core, since all the source bases are slightly different.
WONTFIX, this is NOT a good idea.