Re: How to cope with patches sanely
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
Reply to: