The src:linux-kbuild-2.6 package (and its predecessor, src:kernel-kbuild-2.6-3) were introduced to build a binary package with the subset of the scripts/ subdirectory needed for building OOT modules. The primary reason not to build this from src:linux was that it allowed building src:linux with a minimal cross-toolchain and without the target's glibc development files. In particular, the CI system at kernel-archive.buildserver.net used such minimal cross- toolchains. The source package was subsequently renamed to linux-tools as it was extended to build more userland tools from the kernel source tree. It is been a long time since kernel-archive.buildserver.net was running, so the original reason for the separation no longer exists. If we implement CI using similarly limited toolchains again, we can use a build-profile to exclude userland builds, as these are now well supported. I spent a few hours to attempt a merge of the two packages, the results of which you can see at <https://anonscm.debian.org/cgit/kernel/linux.git/log/?h=benh/merge-linux-tools>. This is a proper git merge that retains the full history of both source packages, including in debian/changelog (which looks rather weird). The binary packages resulting from this merge appear to be functionallythe same, though I can't be certain there's no regression. Advantages of combining the two source packages: - Only one upload needed for each upstream release - They will never be out of sync (see #550379, #573483, #816500) - No code duplication Disadvantages: - Kernel uploads to experimental will be blocked in case of upstream build regressions in tools (usually not too hard to fix) - Build-dependencies for src:linux will be much larger - Build time for userland packages will be much longer The second and third disadvantages are avoidable using build-profiles for kernel vs tools, but I haven't implemented them (yet). I am inclined to go ahead; does anyone have objections to this? Ben. -- Ben Hutchings Always try to do things in chronological order; it's less confusing that way.
Attachment:
signature.asc
Description: This is a digitally signed message part