linux-patch packaging best practice.

[Tim Nowaczyk]

On Aug 10, 2010, at 12:09 PM, Tim Gardner wrote:

> Tim - we're all pretty much git centric and do development ala the upstream kernel community. As such we (the kernel team) don't apply patches to the source package, rather we commit a patch to a local git repository and rebuild. There is a boat load of information in the wiki beginning at https://wiki.ubuntu.com/Kernel about how we maintain the Ubuntu kernel.
> 
I must not have made myself clear.  I'm not trying to get a patch included in the default ubuntu kernel.  In hardy, there were packages like, linux-patch-evms, linux-patch-lustre, and linux-patch-aufs, that would allow the system administrator to add functionality to the kernel on specific systems by installing one of those packages, then runniing make-kpkg --added-patches evms, for example, to build a kernel with the evms extensions.  I created a package that bundled up the web100 patches this way (http://www.web100.org/)  I see that the three previously mentioned packages aren't in lucid.  I installed linux-patch-tomoyo on my lucid machine to see what the new practice is, but it's README says to run "make-kpkg --added-patches", even though "--added-patches" no longer works on lucid (I guess I should file a documentation bug).  So, I think my question still remains unanswered.  Is there a new framework in place in Ubuntu for patching the kernel on an individual machine?  Or is the only solution to update my documentation to say...

apt-get install linux-patch-web100
cd /usr/src/linux
../kernel-patches/all/apply/web100
make-kpkg ...

The web100 patches don't create modules, so I think that means I can't use dkms, right?

Many thanks,
Tim Nowaczyk

--
Timothy Nowaczyk
Network Systems Engineer
University of Virginia - ITC
tan7f at virginia.edu