On Mon, Feb 27, 2012 at 08:14:13AM -0500, Stephen Gallagher wrote:
Personally, my stance on this is that, provided that the forks are
properly renamed such that they will not conflict with other forks of
the same codebase, there's no reason to disallow them. As mentioned by
Toshio in the ticket, carrying forks provides a much better alternative
to bundled libraries in the situations where the primary codebase is
lacking certain features.
There's exactly the same reason to avoid closely-related forks as there
is to avoid embedded libraries - if you have a security issue you now
have more places to fix the same bug. The question is whether that cost
is larger or smaller than the gain from carrying the forked code.
Simple thought experiment: memcpy() has always obviously had destination
and source the wrong way round. I can easily fix that in a forked glibc,
but then I need to rebuild the entire stack on top of that to fix up all
the callers. I think everyone would agree that that was unreasonable.
There's a continuum here, rather than a bright-line test. Any decision
we make (other than "accept everything" or "reject everything") is
going to be somewhat arbitrary.
--
Matthew Garrett | mjg59(a)srcf.ucam.org