[gentoo-dev] [RFC] net-libs/xulrunner-1.9 slotting or not?

[gentoo-dev] [RFC] net-libs/xulrunner-1.9 slotting or not?

[Raúl Porcel]

Okay, so here's the thing: Firefox 3 will be released probably some time 
during this year, as you probably know, they released a few days ago 
beta4 and beta5 will be out probably at the start of the next month or 
so. I started doing ebuilds for net-libs/xulrunner-1.9 and 
www-client/mozilla-firefox-3.0 in the mozilla overlay [1] since november 
2007, mainly thanks to Gergan Penkov's patches on his overlay, info 
available on the forums [2], which i've been adjusting them to do static 
releases and not livecvs ebuilds like he does.

So, firefox-3, seamonkey-2, thunderbird-3 and other mozilla products 
will be using xulrunner-1.9, which is the codebase the mozilla products 
are based on. In fact, everytime you emerge any of those apps, you're 
compiling xulrunner, which takes 90% of the time to build. The good 
thing about those new versions, is that they'll be capable of using the 
xulrunner library installed of the system. So you only have to build 
xulrunner once, and you could build firefox-3, seamonkey-2, 
thunderbird-3 against it, and firefox-3 takes less than two minutes to 
build with shared xulrunner.

Since firefox-3 seems usable now, i was thinking on adding it to the 
tree, however that'll need to add net-libs/xulrunner-1.9. Some apps use 
xulrunner at the moment[3], instead of building against firefox or 
thunderbird or seamonkey. Xulrunner is not mandatory to build firefox-3, 
in fact you can build firefox only with the current ebuilds in the overlay.

Xulrunner-1.9 is a big change, and the apps using it won't work until 
they are fixed. So this needs to be decided, i've been working on 
slotting xulrunner, and i'm ready to put it in the tree. However i'd 
like to see what developers(since they will be the ones who will have to 
deal with this) and users prefer. Even if an app is compatible with 
xulrunner-1.9, it will have to be patched if we slot xulrunner. Since 
the pkgconfig files for xulrunner-1.9 are renamed to avoid collisions 
with current xulrunner-1.8.
The other approach would be not slotting it, p.mask xulrunner-1.9 and 
wait until all the packages work against it and then unmask.
That's what i would like to hear opinions about. Should we slot it, or 
should we not slot it and wait until all the apps are fixed?

Obviously, not slotting it will require to wait until upstream or a 
developer patches the app to work with xulrunner-1.9.

----------------------

On the other hand, you won't be able to use firefox-3, seamonkey-2, 
thunderbird-3 to build an app against, since what the apps needs is 
xulrunner, not firefox or seamonkey.
So whatever is decided, please start fixing your ebuilds that use 
firefox, xulrunner, seamonkey or thunderbird, to stick the DEPEND to 
<www-client/mozilla-firefox-3,<www-client/seamonkey-2,<net-libs/xulrunner-1.9, 
<mail-client/mozilla-thunderbird-3 ASAP.

Thanks

[1] http://overlays.gentoo.org/proj/mozilla
[2] http://forums.gentoo.org/viewtopic-t-556225.html
[3] http://tinderbox.dev.gentoo.org/misc/rindex/net-libs/xulrunner
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] net-libs/xulrunner-1.9 slotting or not?

[Alexis Ballier]

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

Hi,

> Since the pkgconfig files for xulrunner-1.9 are renamed to avoid
> collisions with current xulrunner-1.8.

In general I dont think that is a good idea to do that as you said
we'll have to patch all the rev deps of xulrunner. More importantly
we'll have to carry on those patches forever because we're doing non
"standard" things.

> The other approach would be not slotting it, p.mask xulrunner-1.9 and 
> wait until all the packages work against it and then unmask.

I don't know how hard it would be but I think that's the best option.

Alexis.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] net-libs/xulrunner-1.9 slotting or not?

[Rémi Cardona]

Raúl Porcel a écrit :
> So, firefox-3, seamonkey-2, thunderbird-3 and other mozilla products 
> will be using xulrunner-1.9, which is the codebase the mozilla products 
> are based on. In fact, everytime you emerge any of those apps, you're 
> compiling xulrunner, which takes 90% of the time to build. The good 
> thing about those new versions, is that they'll be capable of using the 
> xulrunner library installed of the system. So you only have to build 
> xulrunner once, and you could build firefox-3, seamonkey-2, 
> thunderbird-3 against it, and firefox-3 takes less than two minutes to 
> build with shared xulrunner.

Brilliant! I thought they had dropped the idea of using xulrunner. Great 
to hear this!

> Since firefox-3 seems usable now, i was thinking on adding it to the 
> tree, however that'll need to add net-libs/xulrunner-1.9. Some apps use 
> xulrunner at the moment[3], instead of building against firefox or 
> thunderbird or seamonkey. Xulrunner is not mandatory to build firefox-3, 
> in fact you can build firefox only with the current ebuilds in the overlay.

Do firefox and seamonkey still provide their own gtkmoz-embed? Are they 
still different (ie, almost the same, but not quite entirely 100% the 
same, although if you look at them they really look the same, but really 
they're not?)

My other question is this, can't we do a big community thing à la Bug 
Day where we make sure that all the apps that currently have 
firefox/seamonkey/xulrunner use flags all build against xulrunner 1.9 
and drop all other keywords for the sake of simplicity?

Anyhow, I'd say mask ff3 and xulrunner 1.9. Better fix things for real 
instead of having our own hand-made workarounds.

Cheers,

Rémi
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] net-libs/xulrunner-1.9 slotting or not?

[Donnie Berkholz]

On 17:12 Sat 15 Mar     , Raúl Porcel wrote:
> That's what i would like to hear opinions about. Should we slot it, or 
> should we not slot it and wait until all the apps are fixed?

Favoring upstream's approach seems to better fit the Gentoo way. If 
upstream doesn't intend it to be slotted, neither should we.

Thanks,
Donnie
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] net-libs/xulrunner-1.9 slotting or not?

[Luca Barbato]

Raúl Porcel wrote:
> Xulrunner-1.9 is a big change, and the apps using it won't work until 
> they are fixed. So this needs to be decided, i've been working on 
> slotting xulrunner, and i'm ready to put it in the tree. However i'd 
> like to see what developers(since they will be the ones who will have to 
> deal with this) and users prefer. Even if an app is compatible with 
> xulrunner-1.9, it will have to be patched if we slot xulrunner. Since 
> the pkgconfig files for xulrunner-1.9 are renamed to avoid collisions 
> with current xulrunner-1.8.
> The other approach would be not slotting it, p.mask xulrunner-1.9 and 
> wait until all the packages work against it and then unmask.

Given the number of applications I'd rather have them fixed with the 
patches pushed to respective upstreams if we got there first.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: [RFC] net-libs/xulrunner-1.9 slotting or not?

[Duncan]

Luca Barbato <lu_zero@gentoo.org> posted 47DCBE68.5000109@gentoo.org,
excerpted below, on  Sun, 16 Mar 2008 07:30:00 +0100:

> Raúl Porcel wrote:
>> Xulrunner-1.9 is a big change, and the apps using it won't work until
>> they are fixed. So this needs to be decided, i've been working on
>> slotting xulrunner, and i'm ready to put it in the tree. However i'd
>> like to see what developers(since they will be the ones who will have
>> to deal with this) and users prefer. Even if an app is compatible with
>> xulrunner-1.9, it will have to be patched if we slot xulrunner. Since
>> the pkgconfig files for xulrunner-1.9 are renamed to avoid collisions
>> with current xulrunner-1.8.
>> The other approach would be not slotting it, p.mask xulrunner-1.9 and
>> wait until all the packages work against it and then unmask.
> 
> Given the number of applications I'd rather have them fixed with the
> patches pushed to respective upstreams if we got there first.

Thanks for the wisdom of asking about this, Raul.  Given the way you 
worded things, it looks like the consensus is heading a way other than 
you might have expected.

Unslotted xulrunner seems to be the consensus, so we aren't committing to 
"forever" maintain patches ourselves -- on a package-base that may well 
expand over time.

Some questions.  What's the possibility of getting upstream to handle the 
renaming, thereby making slotting much easier while eliminating the 
"eternal" patch commitment?  Has the issue even been brought up with 
mozilla-upstream?  I know they aren't always the most receptive to 
community suggestions, but it's worth asking, anyway.

How many packages are we talking about?  Regardless of how we go, fixing 
ten is going to be far easier than a hundred, or five hundred.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: [RFC] net-libs/xulrunner-1.9 slotting or not?

[Luca Barbato]

Duncan wrote:
> Unslotted xulrunner seems to be the consensus, so we aren't committing to 
> "forever" maintain patches ourselves -- on a package-base that may well 
> expand over time.

The consensus is to have updated applications, the new xulrunner seems 
quite an improvement so make _quite_ sense move towards it.

> Some questions.  What's the possibility of getting upstream to handle the 
> renaming, thereby making slotting much easier while eliminating the 
> "eternal" patch commitment?  Has the issue even been brought up with 
> mozilla-upstream?  I know they aren't always the most receptive to 
> community suggestions, but it's worth asking, anyway.

Discussing with upstream this would be good as well, BUT you shouldn't 
rely on that.

> How many packages are we talking about?

A list had been produced already and is relatively short and some are 
just nsplugins (and those shouldn't require a change)

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: [RFC] net-libs/xulrunner-1.9 slotting or not?

[Raúl Porcel]

Duncan wrote:
> Luca Barbato <lu_zero@gentoo.org> posted 47DCBE68.5000109@gentoo.org,
> excerpted below, on  Sun, 16 Mar 2008 07:30:00 +0100:
> 
>> Raúl Porcel wrote:
>>> Xulrunner-1.9 is a big change, and the apps using it won't work until
>>> they are fixed. So this needs to be decided, i've been working on
>>> slotting xulrunner, and i'm ready to put it in the tree. However i'd
>>> like to see what developers(since they will be the ones who will have
>>> to deal with this) and users prefer. Even if an app is compatible with
>>> xulrunner-1.9, it will have to be patched if we slot xulrunner. Since
>>> the pkgconfig files for xulrunner-1.9 are renamed to avoid collisions
>>> with current xulrunner-1.8.
>>> The other approach would be not slotting it, p.mask xulrunner-1.9 and
>>> wait until all the packages work against it and then unmask.
>> Given the number of applications I'd rather have them fixed with the
>> patches pushed to respective upstreams if we got there first.
> 
> Thanks for the wisdom of asking about this, Raul.  Given the way you 
> worded things, it looks like the consensus is heading a way other than 
> you might have expected.
> 
> Unslotted xulrunner seems to be the consensus, so we aren't committing to 
> "forever" maintain patches ourselves -- on a package-base that may well 
> expand over time.
> 
> Some questions.  What's the possibility of getting upstream to handle the 
> renaming, thereby making slotting much easier while eliminating the 
> "eternal" patch commitment?  Has the issue even been brought up with 
> mozilla-upstream?  I know they aren't always the most receptive to 
> community suggestions, but it's worth asking, anyway.
> 
> How many packages are we talking about?  Regardless of how we go, fixing 
> ten is going to be far easier than a hundred, or five hundred.
> 

Upstream won't do that...so i guess this means xulrunner gets unslotted :)
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] net-libs/xulrunner-1.9 slotting or not?

[Raúl Porcel]

FYI this will be finally slotted. Turns out it couldn't be slotted 
because a patch we used that simulated xulrunner-1.8 pkgconfig files. 
But since 99% of the stuff that depends on xulrunner-1.8 won't work with 
xulrunner-1.9, those packages should be fixed by upstream, and they 
should look for the correct pkgconfig files.

Sorry about the mess :)
-- 
gentoo-dev@lists.gentoo.org mailing list