Hi Lars, I do not get your point. If you are concerned that the persons who sent you a package to sponsor have put malicious code in it, what I guess you will first review is wether the scripts you have to execute to test the packages are safe. If you trust the orig.tar.gz tarball and if it has the same md5sum than upstream, having all of the packager's work under the debian directory seems to be an advantage to me. Once it is clear that the packager did not put bad things in the packaging scripts, if inspecting the content of debian/patches is not your preffered way to work, you can run 'debian/rules patch' safely. And if you are doing a lot of sponsoring, how likely is it that cdbs, dpatch and quilt are not installed on your system? In this sponsoring scenario, the benefit of not using a patch system is mostly to have less lines packaging code to audit.
What I thought we were discussing is that there are too many patch systems in Debian, and that people who want to modify existing packages (NMUers, QA team, Security team) can not be requested to learn how to use them to patch the sources ('debian/rules patch' in 99,99 % of the cases), or — more seriously — are annoyed that after having modified an existing package dpkg-buildpackage will fail because 'debian/rules unpatch' will not work anymore. Shall we conclude that the idea of automatically applying the patches when the sources are unpacked is ruled out by the complexity and the side-effect security issues that it would create ? In the end, checking by hand wether a patch system is used is not such a big deal: the information is very obvious in most of the cases, and the standardisation of targets such as 'patch-new', as proposed earlier, would be much more useful. And thanks to the code factorisation through makefile includes, these new targest could be propagated quickly. I just have read a few more messages in this thread. Maybe it is too late here, but sorry, I do not understand everything. I have nothing against change, but if the change is not beneficial to me, and if nobody helps me to understand, how can I change my tools?. I know I will never NMU the glibc or the kernel anyway, so I have no incentive or pressure to study power-tools that will not give me so much benefits in regard to the investment. However, if somebody could take a video of Pierre's talk at FOSDEM, I would be grateful. Any howto for dummies would also be appreciated. Just reading mails saying "your're wrong" with parcellar inline replies will not make me smarter. In the end, this whole thread started because powerusers need patch users to stop using patches, not the reverse. So friends, please come down at our level, and explain us what to do. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]