Summary: | Reqest addition of EPIA patches to Gentoo Sources | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Salim Fadhley <sal> |
Component: | New packages | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | ||
Priority: | High | ||
Version: | 2004.1 | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.epiawiki.org/wiki/tiki-index.php?page=EpiaPatchHowto | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Salim Fadhley
2004-06-26 13:50:50 UTC
Seconded. The epia patchsets at epiawiki.org currently include the bootsplash and supermount patches, which makes them a bit of a pain to apply over gentoo-sources; I'll see if we can get an EPIA-only patchset, which would make adding them to the Gentoo sources easier. These patches should be sent to the upstream kernel, not added to the gentoo kernel packages. yes, these "should" be in the upstream kernel but they won't make it there for a while. These belong in the gentoo-dev-sources for the same reasons as many of the other patches that are or have been in the genpatches (ie. they are worth wile but have not made it in to the upstream kernel). The newer patch with epia only fixes patches cleanly with the current x86 only patches in 2.6.8-r10 but there appears to be a conflict with a via686xxx file from one of the other patches; may just be the patch order. It would be easy to put in a epia use flag and then patch with the current epia patch. This doesn't really qualify as a patch we'd add with our current policy. Adding it to our kernel certainly wouldn't aid the speed at which this would be merged upstream. And we have been over the USE-flag idea time and time again, it won't happen. We could have all sorts of use flags for different functionality and different combinations of them would break in all sorts of different ways. We don't have the resources to go down this route, sorry. |