also sprach Matthew Garrett <mgarrett@chiark.greenend.org.uk> [2003.09.27.1253 +0200]: > There is no good reason for the > grsec patch to require a vanilla kernel tree, merely one that is > slightly less patched than the current Debian one. There is a good reason why grsec can require a kernel source that is 2.4.22 inside, if it says 2.4.22 on the outside. > The right way to deal with this is to be able to trivially patch > and unpatch the kernel source as required during building. If I could request for just the IPsec patch to be removed when grsec patches the kernel, that would be okay, but not acceptable really. Why go through the trouble of unpatching when Debian's really all about bottom-up? On a Debian system, I do not first go off to disable all the useless junk other distributions install. On a Debian system, I do not have to disable all the bells and whistles of some of the programs. I do not have to disable PHP in Apache, I don't have to disable open-relaying in the MTAs. However, I can choose to do all these once the default installation has left me with the basic installation. Why should the patching mechanism around the kernel be different? Now, I understand that security backports are necessary. But even hardware enhancements are out of place, along with feature backports! If I buy a network card known to work with 2.4.22 and up, I would not install 2.4.21 hoping that Herbert would have included the patch. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <madduck@debian.org> : :' : proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
Attachment:
pgpbVPcwhpAmp.pgp
Description: PGP signature