kernel-2 eclass' unipatch feature could automagically use all patches from some hardcoded directory like /etc/portage/unipatch. This way, we'll be able to create ebuilds providing patches to kernel sources like reiser4 support or l7-filter in a much better way than currently. Such ebuilds would only install correct patches in that dir, and they'll be merged into kernel sources on next emerge of them.
Interesting, though this may be problematic: 1. How would we deal with patches that break? (For example, the UAPI header move) Or maybe the question is rather to avoid them breaking. I'm mainly thinking about the order in which patches run here, when would we apply these patches? One could argue to put them at the start so they cleanly apply against the kernel, but then the genpatches would have to work against undefined changes. We can't know which patches could possibly be in /etc/portage/unipatch, it would be exhaustive to make sure that patch sets like genpatches would work about any possible patches that could be put there. So, I think we need to apply the patches from /etc/portage/unipatch after any other patchsets. Though then patches from /etc/portage/unipatch would need to be adapted to apply after the patchsets. I feel that if we do it this way it would be reasonable, since the chance they collide with the limited patches is small; it starts to come problematic with heavier patch sets that are used a lot like hardened or the out-of-tree geek-sources. Tricky business... 2. How do we deal with multiple kernel versions? Creating a folder for each branch likely doesn't work, because a patch may break between two versions in a branch; we also can't make a folder for each version either. Some kind of more advanced logic would be necessary here. We'll need to put some more thought into this before we can implement this.
