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

Re: Debian should not modify the kernels!

On Monday 22 September 2003 14:20, Matthew Garrett wrote:
> martin f krafft wrote:
> >also sprach Matthew Garrett <mgarrett@chiark.greenend.org.uk>
> > [2003.09.21.1=
> >
> >614 +0200]:
> >> Should we stop shipping security fixes backported from development
> >> code?
> >
> >It always depends, doesn't it? We are backporting *security* fixes
> >to packages, but we take care not to introduce new features. I don't
> >oppose some small modifications to the kernel, fixes and security
> >backports, but including a 2.5 IPsec stack in 2.4.21 is kinda not in
> >accordance with that policy, now is it?
> 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?

> 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.

> 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 ...

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. 

The proposed solution of silently unpatching the debian-patched 2.4.22 kernel 
tree with maintainer scripts of any other package  is dangerous... it is even 
funny ... Why cause problem, then struggle how to fix it ... it is better 
just not cause trouble. One does not hit the wall intentionally, then go to 
doctor ;-)

pub  4096R/0E4BD0AB 2003-03-18 <keyserver.bu.edu>
1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 

Reply to: