Status of new source formats project

External Since: Nov 04, 2008 Posts: 144

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-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

External Since: May 12, 2005 Posts: 55

Charles Plessy <plessy.TakeThisOut@debian.org> writes:

> 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

Right, because an individual's use of spoon or chopsticks to eat their
own meal isn't about interaction *between* people; it's a private choice
that affects only that individual.

The analogy doesn't hold for this discussion, since this is about data
interchange formats, which affects *all* parties in the transaction.

See how far you'd get with expecting accommodation of 1% of people using
a different form of currency to pay for their curry rice.

> 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.

Standard data interchange formats is such an argument: one which you
even quoted me as putting forth. The de facto standard data format for
interchange of patch data is unified-diff format.

--
\ "Well, my brother says Hello. So, hooray for speech therapy." |
`\ —Emo Philips |
_o__) |
Ben Finney

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org