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