Non-unified patches and dpkg source format ‘3.0 (quilt)’.
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
Reply to: