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

[Duncan <1i5t5.duncan@cox.net>]

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