Re: [gentoo-dev] [RFC] net-libs/xulrunner-1.9 slotting or not?
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
Re: [gentoo-dev] [RFC] net-libs/xulrunner-1.9 slotting or not?
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] [RFC] net-libs/xulrunner-1.9 slotting or not?
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?
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. signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] net-libs/xulrunner-1.9 slotting or not?
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?
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
