On Sat, 21 Jul 2001, Bastian Blank wrote: > On Sat, Jul 21, 2001 at 08:45:17AM -0300, Henrique de Moraes Holschuh wrote: > > He notes his changes in README.Debian, and most kernel-patch packages will > > work just fine against Xu's patched sources. Those that don't are usually > > easy enough to fix. > > that file isn't include in the bin package also it only describe which > patches are included, not what they really patch, so it is not possible > to follow.
Well, one can file a wishlist bug to get README.Debian included in the binary deb -- feel free to do it, if it bothers you. Including the patch list in the binary deb seems like a damn good idea IMHO As for "what they really patch", the patches are all folded into the debian diff file. If you use CVS or another version control system to track the kernel, the Debian-packaged kernel AND the patches you maintain, it should be straightforward to merge the patches. Again, if you think Xu discloses too little information about the patches he applied in README.Debian, file a wishlist bug asking him to always write down the URI to the upstream patch too. > > 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 And so do we. It's the .orig.tar.gz... > > > 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. Yes, your point being? CVS or bitkeeper, or another version tracking system (including interdiff and paper :P ) should help you there. If it is the lack of the upstream URIs to the patches that is bothering you, you could ask Xu to add that. > also this is almost impossible for security patches like openwall > because they patch files near by the core. Indeed. But that's something that cannot be fixed in any other way than the openwall maintainers packaging a kernel-source-openwall package with the openwall patches folded in. And they better do a damn good job of tracking the kernel ML and whatever patches were folded into the other kernel-source package(s) in Debian, just in case. > must we really include a kernel-source-upstream-* because one maintainer > can't write changelog entries? Well, I don't think we should add yet another damn big package for such a stupid reason. Bug Xu about adding better changelogs; he should do so anyway. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
pgpzYgZC46M9p.pgp
Description: PGP signature
