Bug 216100

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 ;-)