On Mon, Jul 01, 2013 at 09:25:42PM +0200, Tom Wijsman wrote: > On Mon, 1 Jul 2013 14:09:57 -0500 > Matthew Summers <quantumsumm...@gentoo.org> wrote: > > If the patchset patches the kernel's core, it doesn't matter what > > CONFIG_* option is set the core kernel code _has_now_been_changed_. > > This is the crux of the argument, I believe. AUFS simply being one > > example of this. I'm sure there are others. > > As per my response to that point, this statement is no longer true. > > Let me re-iterate it here: > > Earlier I mentioned "3) The patch should not affect the build by > default."; if it does, we have to adjust it to not do that, this is > something that can be easily scripted. It's just a matter of embedding > each + block in the diff with a config check and updating the counts.
Wonderful, now you are maintaining a patch that looks nothing like the one created by the original developers, nor tested by anyone else other than gentoo developers. There's a reason that no other distro does this. Playing fast-and-loose with kernel patches is a fun thing to do, but really, why? Users love doing this type of thing, but the interactions of different kernel patches with core subsystems is almost always a non-trivial thing. I'm not saying not to do this, but consider this a friendly warning that this is going to be a MAJOR pain to maintain and debug over the long-run. But hey, what do I know? It's not like I've ever done this before and had the experience of the resulting fall-out that took years to recover from on user's production systems, causing a number of enterprise Linux companies to swear that they would never do this type of thing again... Personally, I wish you luck, it will push the sane users to the vanilla-sources tree, which I strongly encourage :) greg "kids, get off my lawn!" k-h
