Bugzilla – Bug 216100
Various dependency problems with mozilla-xulrunner/gecko based applications.
Last modified: 2006-11-23 06:40:21 UTC
The packages seamonkey mozilla-xulrunner180 mozilla-xulrunner181 all provide (in the rpm "Provides" sense) Gecko libraries like libgtkembedmoz.so & friends, but only the xulrunners can actually be used for Gecko embedding, and there are two of these. This is problematic; I have identified the following problems so far: (1) seamonkey.spec contains code to filter some libraries out, but it does not cover everyting, most specifically it does not cover libgtkembedmoz.so. (2) Most GNOME applications that use Gecko have an explicit dependency on a specific xulrunner version, which works around the problem and might be "good enough". (3) liferea does not have an explicit dependency on a specific xulrunner version or even xulrunner in general. Therefore, dependency-wise, even seamonkey can fulfill the requirements of liferea. This is undefined behaviour and broken. (4) The situation with gnome-web-photo is similar to that of liferea, but luckily it is linked to libxul.so which only the two xulrunners provide, so the behavior is a little bit less undefined as with liferea. (5) epiphany is totally broken because it has rpm "Requires: mozilla-xulrunner181" even though the binaries in the package are clearly linked to mozilla-xulrunner180. This causes bug 204907. What needs to be done: (1) Decide whether to filter the Gecko libraries out of the "Provides" of seamonkey. It's not strictly necessary, but can maybe prevent future problems if more xulrunners and Gecko based applications are added. (2) Fix gnome-web-photo and liferea to have a "Requires" on the xulrunner version that was used to build them. (3) Fix epiphany which already has an explicit dependency on xulrunner to have a dependency on the _right_ one. I don't know which of the two xulrunners was really intended.
Stanislav, can you take care of this, please?
Yes, I think, that removal of unversioned gecko Provides from all packages is a good idea. Each package then must filter gecko Requires and explicitly specify, which version of gecko it requires. It will break some packages, but the fix will be easy and clean.
No, what I had in mind was: - filter gecko Provides from seamonkey, but not from the xulrunners and not from Requires of other packages; - add versioned Requires too all Gecko-embedding packages in _addition_ to the autogenerated Requires.
Just for clarity: Removing the rpm auto-generated dependencies for all gecko apps is not what I meant. These are not a problem, the only problem is that they are matching multiple packages. Therefore the packages need fixed "BuildRequires" and "Requires" in addition to the rpm auto-generated dependencies. But removing the gecko provides from the xulrunners is not what I meant, this would break 3rd party packages. Only for seamonkey this makes sense because seamonkey does not really "provide" them, only the xulrunners do, but these really do.
OK. Your solution is technically more correct (and simpler to implement).
Packages, which currently contain libgtkembedmoz.so: mozilla-xulrunner180, mozilla-xulrunner181, nvu, seamonkey Packages, which currently provide libgtkembedmoz.so: mozilla-xulrunner180, mozilla-xulrunner181, seamonkey Packages, which currently require libgtkembedmoz.so: blam, devhelp, epiphany, epiphany-extensions, gnome-web-photo, liferea, yelp List is valid also for libxpcom.so, but it is alsos required by seamonkey-* subpackages.
I am just testing packages and it seems, that epiphany is built with 181. Other application can be built with 181, too, without any compilation problems. Should we prefer 180 or 181 for all packages or should we keep half of gnome linked with 180 and other half with 181 (which will probably increase memory requirements)?
It seems to be confusing. epiphany: BuildRequires: ... gecko-sdk ... %if %suse_version > 1010 BuildRequires: mozilla-xulrunner181 ... %endif gecko-sdk is provided by mozilla-xulrunner180-devel. It means, that it tries to load both geckos for build. But in reality it links with 180. So everything is linked with 180.
Yes, epiphany is broken in a way that it claims to be built against 181, but is in reality built against 180 (this can be proven by looking at the RPATH of the binary). That is exactly what led to this bug report: Cleanup of all gecko applications.
All packages can be linked with both 180 and 181. 181 was probably intended for epiphany and can be used for all other packages. So I am doing so. If it will cause any problems, it is simply possible for >= 10.2 to define gecko version in the spec file by: %define xulrunner_version 181 Done for packages: blam, devhelp, epiphany, epiphany-extensions, gecko-sharp, gnome-web-photo, liferea, yelp Note that it may be superfluous for gecko-sharp, which seems to be gecko-version independent and the requirement should be "any xulrunner". But it seems not to break anything to hardcode 181 just now (blam requires it, too).
*** Bug 204907 has been marked as a duplicate of this bug. ***
Gary, why do you dupe the first bug filed to a newer bug? I should file another bug about this and then dupe this one to that.
I have read all related commit messages and it is mostly fine. I have identified one problem, however. Give me some time to write it down together with a solution.
What you're doing for nvu and seamonkey now is: (1) Remove all Provides that come from a private library in the package. (2) Remove all Requires that come from a private library in the package. (1) is correct, but (2) is not. The correct semantics here is: Remove all Requires on a private library which is in the same package. Otherwise you lose some legitimate Requires while keeping some illegitimate ones in. I spent several hours today writing something and didn't come up with something better than what nvu previously had. What nvu previously had was exactly correct: Remove all Provides from libraries in the package, and remove all Requires on (ON, not FROM) libraries files which are part of the same package. Simply revert the last change to nvu and copy the logic from there to seamonkey. That's it.
Fixed for nvu and now also for seamonkey. I hope, that now it is really correct. %if %suse_version >= 1000 cat << EOF > %{my_provides} #! /bin/sh grep -v ^$RPM_BUILD_ROOT/usr/%{_lib}/seamonkey | /usr/lib/rpm/find-provides EOF cat << EOF > %{my_requires} #! /bin/sh /usr/lib/rpm/find-requires | while read ; do if ! test -e $RPM_BUILD_ROOT/usr/%{_lib}/seamonkey/\${REPLY%%%%(*} ; then #) echo "\$REPLY" fi done EOF chmod 755 %{my_provides} %{my_requires} %define __find_provides %{my_provides} %define __find_requires %{my_requires} %endif
thanks a lot! Does this mean we can drop mozilla-xulrunner180 completely? Could you do so, please?
Not yet. We must be sure, that: - Bug 219354 is fixed. - All packages work correctly with 181. - No third party package require 180. Tested & works with 181: devhelp, epiphany, epiphany-extensions, liferea (works with "Unhandled property: 12 border-collapse", but once crashed), yelp (shows lots of probably unrelated warnings) Tested & crashes: blam (bug 215499) Untested: gnome-web-photo
(In reply to comment #8) > It seems to be confusing. epiphany: > > BuildRequires: ... gecko-sdk ... > %if %suse_version > 1010 > BuildRequires: mozilla-xulrunner181 > ... > %endif > > gecko-sdk is provided by mozilla-xulrunner180-devel. It means, that it tries to > load both geckos for build. But in reality it links with 180. > > So everything is linked with 180. Unfortunately I've missed this bug up to now. I wonder if people were reading my mails a few months ago. (No I'm not wondering since it's clear that they haven't.) http://lists.opensuse.org/opensuse-packaging/2006-08/msg00046.html (and I'm pretty sure I've sent another one to gnome-maintainers)
May I carefully ask for the status here? - The yastbrowser works with *181, actually it even requires *181. - Stanislav has tested all dependent packages and says that all except blam and gnome-web-photo are working. - I have tested gnome-web-photo and it works for me. - I have a strong indication that the blam crash is unrelated to the xulrunner version because basically the same report exists also in the Debian bugtracker (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=385875) and Debian still uses *180. IMHO you should really try to avoid shipping two xulrunner versions, as it means double work and double bandwidth usage in case of a security update. Standardizing on a single version simplifies everything a lot. What should be done IMHO is: - Smoke-test gnome-web-photo. Do gnome-web-photo http://www.opensuse.org/ opensuse.png gnome-web-photo https://bugzilla.novell.com/show_bug.cgi?id=216100 bugzilla.png If you get PNG files, the application can be considered basically working. - Do a test build of gecko-sharp and blam against the old xulrunner package on x86_64. It must be x86_64 because the crash doesn't happen on i586. If this one crashes, too, then the xulrunner version is not the problem and there is no value in keeping the *180 package around. - If the above tests succeed, transfer the compatibility Provides/Obsoletes from *180 to *181 and get rid of *180 for good.
Tested & works with 181: gnome-web-photo Tested & crashes consistently with both 180 and 181: blam (bug 215499)
AFAIK, no package depends on mozilla-xulrunner-180 any more. Should we add Obsoletes (not Provides) to 181 and drop 180 for 10.2 or should we do it for 10.3?
drop 180 for 10.2! Rudi, do you agree?
I'm all for dropping it now. # whatdependson mozilla-xulrunner180 - no dependent package found
Don't forget to transfer the "Obsoletes" tags from *180 to *181 for a smooth upgrade path: mozilla-xulrunner181 obsoletes mozilla-xulrunner mozilla-xulrunner181-devel obsoletes gecko-sdk
Done: --- mozilla-xulrunner181.spec +++ mozilla-xulrunner181.spec @@ -20,7 +20,9 @@ Group: Productivity/Other Provides: gecko181 %if %suse_version > 1010 -#Obsoletes: mozilla-xulrunner +Obsoletes: mozilla-xulrunner +# For upgrade from 10.2 betas: +Obsoletes: mozilla-xulrunner180 %endif Source: xulrunner-source-%{version}.tar.bz2 Source1: l10n.tar.bz2 @@ -79,10 +81,11 @@ Summary: XULRunner/Gecko SDK 1.8.1.x Group: Development/Libraries/Other %if %suse_version > 1010 -#Obsoletes: gecko-sdk +Obsoletes: mozilla-xulrunner +Obsoletes: gecko-sdk +# For upgrade from 10.2 betas: +Obsoletes: mozilla-xulrunner180-devel %endif -Conflicts: mozilla-xulrunner180-devel -Conflicts: gecko-sdk %if %has_system_nspr Requires: mozilla-nspr-devel >= %( echo `rpm -q --queryformat '%{VERSION}' mozilla-nspr-devel`) %endif @@ -104,6 +107,11 @@ Summary: Translations for XULRunner 1.8.1.x Group: Productivity/Other PreReq: %{name} = %{version} +%if %suse_version > 1010 +Obsoletes: mozilla-xulrunner-l10n +# For upgrade from 10.2 betas: +Obsoletes: mozilla-xulrunner180-l10n +%endif %description l10n XULRunner is a single installable package that can be used to bootstrap
nit: we never had a mozilla-xulrunner-l10n package ;-)