Greg Folkert <[EMAIL PROTECTED]> wrote: > > So which of the 11 platforms _REQUIRE_ the IPSEC backport? If any, what > is the rational that they *REQUIRE* that piece.
As the current maintainer of kernel-source, I decide which patches are included per default. The individual architecture maintainers can choose to override my decisions through architecture patches. 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. >> 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. > 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. Cheers, -- Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ ) Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt