[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian should not modify the kernels!

George Danchev wrote:
>On Monday 22 September 2003 14:20, Matthew Garrett wrote:
>> It would be inappropriate to do it within a stable release, sure, but it
>> is something that Debian do do in general. 
>Then all kernel-source-x.y.z prepared like this kernel-source-2.4.22 2.4.22-1 
>will never be release-ready or candidates for Stable (so sad). Then why it 
>has been introduced to official Debian archive?

You've misunderstood me. It would be inappropriate to add backported
features to a stable update. It's entirely appropriate to do so before
the package enters stable, providing that this doesn't compromise the
functionality of the package.

>> In this case it's a chunk of
>> code that has almost nothing to do with the core kernel code - it just
>This is very arguable. Have you apt-get source kernel-source-2.4.22 
>then looked at the patch ?


>> so happens that in the pathological case of a kernel patch, there's some
>> awkwardness. 
>it is not a pathological case, this is how the patch program works: it reads 
>the patch file (prepared with diff) and tries to find the relevent rows in 
>files within the tree it is patchng, if these rows are missing or fuzzy then 
>what do you expect the patch program to do, it simply can not replace them 
>out ? it is not like a programmer to merge it manually and checks to ensure 
>that there are no logical errors introduced during the merge.

Additional kernel patches are not the norm, and are the only case where
current policy causes problems. They're a pathological case.

>> That's an indication that our kernel patching system should
>> be rationalised, not that shipping modified kernels is wrong.
>No, that is an indication that kernel-source-x.y.x is moving target and you 
>will always have issues paching it ...

Of course it's a moving target. It's a large chunk of code that changes
significantly between minor version numbers. The solution here is for
developers to work together in order to work out which parts of the
Debian patches are essential, and which are "value added". The latter
ought to be either easily strippable or added later, allowing users to
customise things more easily.

>Do not get me wrong. I'm not against shipping modified kernels, but do not it 
>Red Hat way having 2.6 stuff shipped with names like kernel-...-2.4... It is 
>not 2.4.x then ... If I want such behaviour I'll run Red Hat... so please do 
>not kill the only one and true/safest/sanest GNU/Linux harbor around ... e.g. 

And our SSH isn't 3.4p1 either.
Matthew Garrett | mjg59-chiark.mail.debian.devel@srcf.ucam.org

Reply to: