Re: How to cope with patches sanely
Le Thu, Jan 31, 2008 at 10:54:03AM +0200, Lars Wirzenius a écrit :
> Perhaps it would be better to make the creation of the source package
> create a .diff.gz that already has the patches applied? This may be
> more complicated to change, and probably requires changes to how the
> patch systems are used.
Hello Lars,
Basically it would mean to have the clean rule call calling 'patch'
instead of 'unpatch', isn't it? I think that it would defeat the reason
why people use patch sytems: to break out the .diff.gz into logical
parts. If packages start to have half of the diff.gz originating from
patches, and half from direct modificaitons to the source, it will turn
into a horrible mess, especially that the unpatch rules can not be
guaranteed to work in this case. As Teemu Likonen wrote in his latest
email, to be able to repack patched sources after modification, it would
be required to interact with the patch systems to generate a new patch.
But this is adding a lot of complexity.
I am wondering if just mandating 'debian/rules patch' to work if
debian/patches exist shouldn't be just sufficient. Correct me if I am
wrong, but aren't most of the people using patch systems working in
teams? In that case, NMUers can simply make a diff between modified and
untouched sources, and send it via a bug report: one of the purposes of
team work is to ensure high responsivity. In the case of packages
maintained by MIA developpers, getting rid of the patch system could be
a viable option, since it means that nobody cares for the package
anyway.
But I am still missing something: how can we get the benefits of using a
patching strategy, that is to break up changes into logical components,
with the VCS strategy? I would't mind swiching, however I do not know
for others, but for me it would require some help and explanations.
Have a nice day,
--
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan
Reply to: