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

["Raúl Porcel" <armin76@gentoo.org>]

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