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

Re: Debian should not modify the kernels!

On Sat, 2003-09-27 at 23:10, Herbert Xu wrote:
> Greg Folkert <greg@gregfolkert.net> wrote:
> > 
> > So  which of the 11 platforms _REQUIRE_ the IPSEC backport? If any, what
> > is the rational that they *REQUIRE* that piece. 
> As for the criteria for inclusion, I have already outlined some simple
> rules earlier in this thread.  I would recommend you to read it if you
> are interested.

Yes but those criterion fail to mention why it is required in the Debian
Kernel Source. I understand it should be in the default Binary images...
but as for inclusion into the default source, still begs the question
_why_ is it required, as your simple statement doesn't cover that.

As far as benefits it provides *I* can see it being beneficial, but
still fail to see why since the entire "thrust" of Debian is all about
choice and not including everything by default and making some things
optional. I really have no problem with the distributed Binary Kernels
including this patch, but do think additional feature should be included
as a patch *to* the source, not *for removal*. 

And, just for grins and giggles here, if lets say that 90% of the
patches available to the patch system were, in fact, actively maintained
and have been/are candidates for inclusion in the Kernel by the Kernel
Core Team (err maybe just Linus) would you then be including all of them
as included patches and backports to the Debian Kernel source 2.4?

One more thing, why have you not included the IPSEC piece in the 2.2
Source then? 

> >> If someone wants to make a kernel-patch package out of it, go right
> >> ahead.
> > 
> > Would that then allow you to NOT include it in the kernel-source
> > package, but then make it a "standard" patch to be installed by default
> > then? And have a Variable "NO_IPSEC_PATCH" or something similar so that
> > kpkg doesn't apply it... but does apply other patches.
> No, the purpose of such a kernel-patch package would be to allow a user
> to easily obtain the IPSEC patch should they wish to either apply it
> to a vanilla kernel, or unapply it from the Debian kernel.
> Its existence is orthogonal to whether this patch is included in the
> Debian kernel source.

Again, why should it be orthogonal, seems opposite about why we even
HAVE the Kernel Patching in kpkg at all then. Let us go back to using
patch then.
> > But exactly why should this particular patch (IPSEC backport) cause so
> > much grief for the patch system, if it were to be so standard?
> I do not believe that this patch has caused excessive grief for the
> benefits that it brings.  In fact, conflicts between the Debian kernel
> source and random kernel patches floating around are a fact of life.
> For example, the grsecurity patch has had a history of conflicts with
> various patches in the Debian kernel source.  Most of those patches that
> caused conflicts were in fact essential security fixes.  You can review
> this for yourself by visiting to the BTS entry for the grsecurity
> package.

To be honest you are very right in this, in general though, why should
you add insult to injury on this by making the the situation worse? 
Granted grsecurity and a few other patches, really "screw" with the
source quite a bit, but I still fail to see why these need to be
included by default

Might just be we agree to disagree? And if I felt compelled to... could
I maintain a kernel-source that only has bug and security fixes in it
with no additional features added? Would you sponsor it? (Rhetorically
greg, greg@gregfolkert.net
REMEMBER ED CURRY! http://www.iwethey.org/ed_curry

Your eyes are much like milky pools of pantyhose.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: