Re: http://debian.linuxwiki.de/DebianKernel_2fPlan
Christoph Hellwig <hch@lst.de> writes:
> 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.
What do you name linux-2.6.6-amd64-generic-1_2.6.6-1_i386.deb then?
^name ^KVER ^ARCH ^flavour^revision ^package arch
^dpkg version
Is the amd64 then 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.
Its all modules anyway. The package size is less important than the
number of packages.
>> 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.
No. Please don't. The build-time and the amount of rebuilds needed
makes such an undertaking impossible.
>> * do not include features in the basic kernel-source, make them
>> individual patches. security patches should be okay.
>
> 100% agreed
MfG
Goswin
Reply to: