http://debian.linuxwiki.de/DebianKernel_2fPlan
First time I see this wiki page. Comments:
> new naming scheme getting rid of "image" as part or package names (only
> for Provides: - compatibility issues), instead, distinguishing between
> linux and hurd. First idea:
>
> linux-kernel-source-KVERS
>
>
> linux-kernel-KVERS-ARCH(-SUBVERS) (plus extras, see below)
remov the -kernel, linux is the kernel, and upstream tarballs are
linux-$version, too.
remove the -arch, it'll be .$arch.deb anyway, rather add a -flavour.
> minimize the number of pre-built kernel images in the archive. providing
> a reasonable set of kernel configurations for use with an improved
> kernel auto-building package for users would deliver the same
> flexibility with less impact on Debian's autobuilder, archive, and
> mirror network
ACK
> 386 (compatibility kernel)
>
> 586-ws (workstation kernel, preempt+lowlatency, multimedia optimised)
> 686-srv (server kernel, smp, highmem)
pretty x86-centric, heh? :)
not sure about the choice, but the server vs workstation split doesn't
make sense in these days of commodity SMP and HT and large memory. And
multimedia optimised sounds like buzzword bingo to me.
I'd rather see a 386-up kernel, and i686 up/smp kernels. That leaves no
pre-build kernels for the i386 and i585 smp boxens, not sure whether
that matters.
> split modules into subpackages, targeting at different production fields:
probably makes sense.
> clear line between upstream source and our patches
see discussion on this list :)
> * architecture support patches hard to apply unless the main kernel-source
> package is "pristine"
as mentioned a few times architecture packages should be part of the
main kernel-source to avoid a big maintaince mess
> * make sure that even the "pristine" tarball contains minimalistic
> information about its status in Debian (packagename, version), so it
> would be easier to create meta-source packages with kernel-builder
> * deliver architecture-independent changes as a "debian" patch
tend to disagree here. the .diff.gz of kernel-source (or whatever it's
called) should contain all patches needed to build all images.
> * do not include features in the basic kernel-source, make them
> individual patches. security patches should be okay.
100% agreed
Reply to: