Duncan wrote:
Luca Barbato <[EMAIL PROTECTED]> posted [EMAIL PROTECTED],
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
