On Monday, July 01, 2013 01:52:10 PM Rick Zero_Chaos Farina wrote: > On 07/01/2013 01:35 PM, Tom Wijsman wrote: > > On Mon, 01 Jul 2013 12:20:09 -0400 > > > > "Rick \"Zero_Chaos\" Farina" <zeroch...@gentoo.org> wrote: > >> Some patches are reasonably easy to combine, such as genpatches and > >> aufs. Some patches are difficult to combine, such as hardened and *. > >> When you combine hardened patches and aufs (for example) you need > >> extra patches. I would be THRILLED to see the number of sources cut > >> down, but hardened-sources must be it's own thing (that said, I'll > >> personally maintain the aufs patches for hardened if they wanted to > >> add a USE=aufs flag). > > > > Yes, gave it as an quick example but I indeed remember from going > > through the sources ebuilds that hardened ebuilds do quite some things. > > I think the downside from extending genpatches is that hardened-sources > > can no longer rely on it, but we'll have to see that as we go forward. > > > > I don't think that apart from hardened the optional patches on their own > > are hard to combine; they each have their own separate goal, I don't > > see them conflict on anything. If it happens once in a while, we can > > still maintain them to work together. > > Hardened has K_WANT_GENPATCHES="base" which means it already doesn't > take the extra patches. We could either introduce a new flag for your > patches like K_WANT_GENPATCHES="base extra geek" or more likely make > each one with their own name so that hardened et al can take what they > like and leave the rest.
Ok, so I have talked to Tom about this on IRC and it's probably prudent to chime in. I have gotten many complaints in the past that there is not enough in g-s, and, of course, I've gotten complaints about there being too much. I have 'relaxed' a tad about what I think should be in g-s, but maybe it has gone a bit farther than I wanted it too. I would like to see a "-experimental" use flag and base,extras,geek (whatever) so that g-s goes back to what it's original goal was with nothing non-upstream unless the user does a configuration change themselves. This will actually help us solve both issues. 1) it will allow us to pull g-s back to it's original goal as a minimal kernel sources with upstream only patches. 2) we can carry some patches from upstreams trees that possibly aren't yet in -next, or not yet accepted to mainline but do provide some benefit to a smaller group of our users. (Thinking about our thinkpad patches) -- Mike Pagano Gentoo Developer - Kernel Project E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index
