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

[Raúl Porcel]

Duncan wrote:
> Luca Barbato <lu_zero@g.o> posted 47DCBE68.5000109@g.o,
> 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@l.g.o mailing list