Le Wed, Aug 05, 2009 at 03:45:00PM +1000, Ben Finney a écrit : > > The point, rather, seems to be that unified-diff format is the de facto > standard format for exchanging patch information.
Le Wed, Aug 05, 2009 at 10:53:21AM +0200, Michael Banck a écrit : > > It's the preferred format for 99% of all Free Software work/projects > AFAICT. In my workplace's cafeteria, 99 % of the people eat curry rice with a spoon, and 1 % with chopsticks. But this is causing no trouble, and never the spoon users ask the chopsticks users to change their instrument (and I can tell you that I do not leave a single grain of rice when I eat my curry rice with chopsticks). I am all for campaigning for the unified diff format if there are arguments on which I can base a discussion with Upstream, but a mere cultural preference, be it the one of a very large majority, is a too weak argument. The only practical argument currently is the regression between the dpkg format 1 to 3.0 (quilt), where non-unified patches in debian/patches cause the source package to be not buildable, only because the Dpkg maintainers decided to reject non-unified patches despite they can be applied by the patch command they use in Dpkg::Source::Patch.pm. How is that relevant for Upstream ? After deleting the following check, my source package builds fine. --- a/scripts/Dpkg/Source/Patch.pm +++ b/scripts/Dpkg/Source/Patch.pm @@ -325,9 +325,6 @@ sub analyze { unless (defined($_ = getline($diff_handle))) { error(_g("diff `%s' finishes in middle of ---/+++ (line %d)"), $diff, $.); } - unless (s/^\+\+\+ //) { - error(_g("line after --- isn't as expected in diff `%s' (line %d)"), $diff, $.); - } $_ = strip_ts($_); if ($_ eq '/dev/null' or s{^(\./)?[^/]+/}{$destdir/}) { $fn2 = $_; Why not just applying the patches and catch errors if there are, instead of writing a new patch parser from scratch just to check that it looks like being in the unified format? Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org