On Wed, Dec 12, 2007 at 10:08:06PM +0100, Mike Hommey wrote: > On Wed, Dec 12, 2007 at 01:31:56PM +0100, Alexander Sack wrote: > > How about shipping like ubuntu, and then switching to a shared glue, > > once you have a suitable patch? We could even upload as xulrunner-1.9 > > so the transition could take some time. But having something in sid > > now would be beneficial imo. > > It wouldn't be beneficial because it wouldn't be useable by any reverse > dependency. And it wouldn't build on a lot of architectures, and lacks a > whole bunch of patches we apply for good reasons. If it's only about > having a running xulrunner 1.9 for people that want it, they can take > nightly builds on mozilla.org.
The fixes for the archs need adaption anyway. And from what I know, in debian you usually don't get all archs built with the first upload anyway, and the maintainer probably cannot/does not want to fix the rare archs on its own. So uploading now without those patches is beneficial and it allows porters start to work on the patches _now_ and not after the release. ATM, there is still time to get things into upstream tree without much hazzles. Anyway, what are the patches you want want to see ported to xulrunner-1.9 (without the archs of course)? > > > For the question about the versioned pkglibdir ... why do you want to > > drop the versioning from the pkglibdir? I mean, usually one shouldn't > > ask: why to not diverge from upstream, but instead review the > > arguments that led to the current diff. Given that -rpath linking > > isn't the way to go anymore, I don't see any benefit out of shipping > > a non-versioned dir. > > Off the top of my head, this has at least these benefits: > - Allow other packages to reliably put files at the correct place (think > extensions, plugins, or even diversions) we provide stable directories for those parts of xulrunner/firefox that allow packagers to drop something in: for now its /usr/lib/xulrunner-addons/[plugins,extensions] and the same for firefox-addons. > - Smoother upgrades I don't get this ... replacing files underneath a running application rarely did any good on upgrades either. > - Allows users to actually install mozilla.org's versions without > overwriting ours ! > Well, users must not install it in /usr/, but rather /usr/local/ or somewhere else. So this point isn't valid. > And we only ship one xulrunner at a time anyways. For now this might be true, but you could also allow smoother transitions to new versions if you would allow xulrunner and xulrunner-1.9 (and next time xulrunner-1.9.1) to reside on the same machine for some time. (like what we do in ubunt atm: migrate rdepends one by one from firefox/xulrunner to xulrunner-1.9 without breaking the rest). This takes some pressure of the packager to come up with patches for all at once and allows you to release-early and often. Why do you think this is a bad thing? > > Now, the thing that is pissing me off is that while they actually did > what they told, and dropped gtkmozembed in favour of having embedders > use the xpcom glue and have it dlload libxul.so, their applications > (firefox, etc.) are *not* embedders, and *do* link against > libxul.so. Their applications use the dependent glue, because they get loaded in a running xpcom environment (but i guess you know that). But why does it matter? Embedders can either choose to ramp up their own xpcom through the standalone glue ... or can decide to be run as a xulapp using the dependent glue (e.g. linking against libxul). For the rdepends, we have a set of patches already. Those are not yet complete, but will eventually go upstream. So once this is sorted out there won't be any issue. Instead things will have improved, because all this MOZILLA_FIVE_HOME and rpath mess is gone once and forever. (While it would have been nice to be able to just recompile, it had to happen at some point anyways. So lets do the transition of the rdepends to use the glue now and help upstream to properly use it ... and things will be better.) > If we want to link these applications properly, and have the > dependencies properly handled by dpkg, I guess we won't have much > choice, though using the new symbols feature of dpkg-shlibdeps, it is > possible to have the build dependencies right even without a SOVERSION. > The problem with this is that backports won't be possible. yes, while i don't see a big problem requiring embedders to explicitly depend on xulrunner-1.9, I see that we could improve the dpkg integration. Using dpkg-shlibdeps would be a choice, yes. - Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
