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 asked) -- 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