On Thu, Oct 27, 2005 at 01:54:24PM +0200, Marc Haber wrote: > this is basically a re-hash of > http://blog.zugschlus.de/archives/231-Thoughts-about-the-Debian-kernel.html, > which I published on my blog on sunday. Since the article received > less response than I originally expected, I would like to solicit your > opinions and answers in a more direct way.
the comments show a funny public you reached. > I am one of the guys who builds Linux kernels locally, from vanilla > sources. What I don't like in this approach is that I do not get the > distribution patches and might miss one of the kernel security > patches, since I am way too busy to keep track of LKML any more. > otoh, I am kind of a version number junkie when it comes to the > kernel, so the Debian kernel sources even in sid frequently are not > current enough. So, what I want to have is a compromise between a > vanilla kernel and the Debian distribution kernels, built in a way > that the images integrate well with Debian. then use latest stable. the addition of this tree helped a lot in the maintenance of the debian kernel. chris wright and greg kroah-hartman do a fantastic job. > This message contains a few questions and wishes directed towards the > Debian kernel team which I failed to get addressed on #debian-kernel > and on the blog. > > * The build process is not very transparent > * Documentation in the README files seems quite incomplete > * In my opinion, answers to these questions are missing: > * Which steps happen in which order (prose)? README.build in svn?? > * Are there any hooks to interfere with the build process? > * How to keep patches from being applied? naah, you were already told: take it as whole or forget about it. > * How to add local patches? just add them to the debian-patches dir and the latest series file. or like m68k and hppa that still use big sepperate patches in patches-arch. we hope that will evolve as more and more bits land upstream. > * Is there anything like dpatch-edit-patch for the > (home-grown?) patch system in the Debian kernel source package? no. dpatch was never used afair. > * How do I control generation of the > kernel-image-2.x-<flavour>_2.x.y-z_<arch>.deb helper packages? > They do not seem to be controlled by debian/arch/<arch>/defines > as the real kernel debs do. -> debian/templates/control.extra.in > * Can I have patches from a kernel-patch-foo Package automatically > applied for certain flavours? > * Are there hooks for building external modules? > * Are there debian/rules parameters or environment variables to > select only a certain kernel to be built (like for debugging > problems)? > * Can build of helper packages (-headers, -doc, -patch, -source, > -tree) be disabled? > * For local kernel builds, should one use the Debian kernel build > system, or continue to use make-kpkg as it was usual previously? > * there is nothing like a kernel HOWTO > * The Kernel Handbook needs to be fleshed out in these regards. I > might want to contribute once I have accumulated the knowledge needed > to write the passages. cool. > * Patches like, for example, amd64-int3-fix need to be better commented > * I think it is necessary that a patch file contains information > * what does the patch do? > * why is it applied? > * is it necessary only on certain archs? > * is it necessary only if certain drivers are in use? > * what does happen when it is omitted? > * is it security relevant? > * CAN/CVE number, if applicable. naah the last fits into changelog. dont poke with the patches themself. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
