Hi List. We have a kernel devel/build/deploy workflow for our project that evolved in ad-hoc way with hacks and kludges added on top of what we had when we needed changes. It is very cumbersome and in many ways broken and buggy so we have motivation to clean up the technical debt. Here is how our build workflow loks like now: 1) untar the tarball with debian and our patches integrated in it 2) build it with make-kpkg into a .deb archive 3) unpack the .deb, compile additional modules 4) copy modules to initrd and copy vmlinuz to /boot
This is insane in many ways. What we're planning to do is: 1) keep kernel sources with debian patches and our patches in a git repository. With nice history and patches from different parties (vanilla kernel vs debian patchset vs our patchset) cleanly separated by git tags. (this eases life considerably for development) 2) clone/checkout the repository and build kernel and modules 3) then build external modules that we need 4) then package the kernel with modules in a ways to make the needed modules available in initrd and rootfs (this is still under discussion). So I have a few questions: 1) I believe the use of make-kpkg is recommended for good reasons (what reasons btw?). So I'd like to keep using it (--added-modules look very nice). I'm just not sure if I should. Do you think sticking with make-kpkg is a good idea and why? What value would make-kpkg add to our workflow that we we would have to reinvent if we get rid of make-kpkg? 2) do you maintain a debian kernel repository somewhere? What is the debian maintainer's kernel workflow? Maybe we should just do what you do. 3) Do you have any comments or warnings against what we are trying to do? Thank you. Ivan. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/35f0ddd10ebb8642bccd45460cf731b4d3c...@wal-mbs04.global.avidww.com
