On Mon, 2012-02-27 at 15:18 +0000, Matthew Garrett wrote: > 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. > This is true, but it's also much more visible that the bug needs to be fixed. With a static library, the community as a whole may be unaware that the library is even in use under the hood. > 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. > I think this is a bit of a straw-man. As I mentioned in my earlier email (maybe I was ambiguous), I think that forks should be permitted so long as they are parallel-installable. This means that they should not rely on any of the same headers or use the same shared library name. With this caveat, it becomes possible to have two parallel glibc stacks on the system (ridiculous though that may be). You would have to choose to build against libc-fixedmemcpy.so instead of libc.so. > 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.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
