also sprach Eduard Bloch <email@example.com> [2003.09.22.1155 +0200]: > And if you meant the kernel-source package, then please think > twice before you request a such thing. Your "idea" would require > dozens of versions of kernel-source-NUMBER-foo every time when > I a small fix had to be applied. Why? No, it would require one kernel-source package which installs the kernel source, not the Debian-modified kernel source. > Reality check please. grsec modifies the kernel so heavily that it > will ALWAYS conflict with something when you modify the kernel > a bit more that with trivial bugfixes. Yeah, but that something I can work around. I am not willing to port grsec to a new IP stack or other new features. There is your reality check. > The same would happen if it conflicts with ANY of the 93 > kernel-patches in the archive - there is no reason for rants on > -devel. I am not arguing this. > > significantly modified; why aren't those modifications > > distributed as seperate kernel patches / debian packages in the > > same way grsec is? > > Martin can _simply_ create an alternative "apply" script which > unpatches the Debian source when needed before applying the grsec > patch. Quiet, transparent solution. So then what happens if a user falsely employs the Debian 2.4 kernel feature "IPsec" and one day decides to use GRsecurity? This is a bad suggestion. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <firstname.lastname@example.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!
Description: PGP signature