On Sat, 21 Jul 2001, Bastian Blank wrote: >... > > You will notice that most other distros do the same. RedHat and SuSE > > distribute _heavily_ patched kernels, for example. Debian's is actually > > quite light as far as patches go. > > but they also include vanilla kernelsources
You don't want to use vanilla sources of the 2.4 kernels - look at the Debian changelog of the kernel-source-* packages and tell me which of the patches aren't really needed. > > > I don't think that every patch maintainer has to modify his patches to > > > be compatible with the GNU/herbert kernel, right? > > Wrong. They do. If it is too much of a bother for a maintainer, he should > > orphan the package -- he doesn't care enough about that particular package > > to maintain it IMHO. Do it right, and integrate it well with the rest of > > Debian, or do not do it at all; again IMHO. > > the kernelpatch maintainer can only make their work if they can track > the changes and see that they doesn't interfer with it patches. > also this is almost impossible for security patches like openwall > because they patch files near by the core. 1. Does e.g. a "Fixed a typo in Documentation/sound/OPL3-SA" interfer with openwall? 2. Look at the Debian-diff and you'll see all the changes - and you can use e.g. interdiff to see _exactly_ what changed between two kernel-source-* packages. > must we really include a kernel-source-upstream-* because one maintainer > can't write changelog entries? 1. A 100% unpatched kernel-source-2.4.* package wouldn't help anyone because such a package would currently be too buggy. 2. My experience is that Herbert is very responsive when someone makes suggestions that sound reasonable. > bastian cu Adrian -- Get my GPG key: finger [EMAIL PROTECTED] | gpg --import Fingerprint: B29C E71E FE19 6755 5C8A 84D4 99FC EA98 4F12 B400
