Bug 216100 - Various dependency problems with mozilla-xulrunner/gecko based applications.
Summary: Various dependency problems with mozilla-xulrunner/gecko based applications.
Status: RESOLVED FIXED
: 204907 (view as bug list)
Alias: None
Product: openSUSE 10.2
Classification: openSUSE
Component: Other (show other bugs)
Version: Beta 1
Hardware: All All
: P5 - None : Major (vote)
Target Milestone: ---
Assignee: Stanislav Brabec
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on: 219354
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-29 01:48 UTC by Andreas Hanke
Modified: 2006-11-23 06:40 UTC (History)
3 users (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Hanke 2006-10-29 01:48:57 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.
Comment 1 Andreas Jaeger 2006-10-30 13:48:50 UTC
Stanislav, can you take care of this, please?
Comment 2 Stanislav Brabec 2006-10-31 12:43:21 UTC
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.
Comment 3 Andreas Hanke 2006-10-31 21:05:01 UTC
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.
Comment 4 Andreas Hanke 2006-11-01 07:40:51 UTC
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.
Comment 5 Stanislav Brabec 2006-11-01 13:58:58 UTC
OK. Your solution is technically more correct (and simpler to implement).
Comment 6 Stanislav Brabec 2006-11-01 14:11:42 UTC
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.
Comment 7 Stanislav Brabec 2006-11-07 17:39:59 UTC
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)?
Comment 8 Stanislav Brabec 2006-11-07 17:54:22 UTC
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.
Comment 9 Andreas Hanke 2006-11-07 18:08:51 UTC
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.
Comment 10 Stanislav Brabec 2006-11-07 18:28:37 UTC
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).
Comment 11 Gary Ekker 2006-11-07 22:17:16 UTC
*** Bug 204907 has been marked as a duplicate of this bug. ***
Comment 12 Felix Miata 2006-11-07 22:56:44 UTC
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.
Comment 13 Andreas Hanke 2006-11-10 12:14:58 UTC
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.
Comment 14 Andreas Hanke 2006-11-10 15:45:37 UTC
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.
Comment 15 Stanislav Brabec 2006-11-15 16:29:51 UTC
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
Comment 16 Andreas Jaeger 2006-11-15 19:02:00 UTC
thanks a lot!

Does this mean we can drop mozilla-xulrunner180 completely?  Could you do so, please?
Comment 17 Stanislav Brabec 2006-11-16 10:00:56 UTC
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
Comment 18 Wolfgang Rosenauer 2006-11-16 10:41:22 UTC
(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)
Comment 19 Andreas Hanke 2006-11-22 03:51:37 UTC
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.
Comment 20 Stanislav Brabec 2006-11-22 15:16:49 UTC
Tested & works with 181:
gnome-web-photo

Tested & crashes consistently with both 180 and 181:
blam (bug 215499)
Comment 21 Stanislav Brabec 2006-11-22 15:18:26 UTC
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?
Comment 22 Andreas Jaeger 2006-11-22 15:22:56 UTC
drop 180 for 10.2!

Rudi, do you agree?
Comment 23 Ruediger Oertel 2006-11-22 15:30:55 UTC
I'm all for dropping it now.
# whatdependson mozilla-xulrunner180
- no dependent package found
Comment 24 Andreas Hanke 2006-11-22 15:38:08 UTC
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
Comment 25 Stanislav Brabec 2006-11-22 16:35:51 UTC
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

Comment 26 Wolfgang Rosenauer 2006-11-23 06:40:21 UTC
nit: we never had a mozilla-xulrunner-l10n package ;-)