Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Jan 1998 17:01:45 -0800 (PST)
From:      asami@cs.berkeley.edu (Satoshi Asami)
To:        ache@nagual.pp.ru
Cc:        peter@netplex.com.au, perhaps@yes.no, gpalmer@FreeBSD.ORG, ports@FreeBSD.ORG, committers@FreeBSD.ORG
Subject:   Re: amanda port, empty PATCH_STRIP= lines causes trouble
Message-ID:  <199801210101.RAA19809@baloon.mimi.com>
In-Reply-To: <Pine.BSF.3.96.980120153843.24732A-100000@lsd.relcom.eu.net> (message from =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= on Tue, 20 Jan 1998 15:54:45 %2B0300 (MSK))

next in thread | previous in thread | raw e-mail | index | archive | help
 * > (1) ncurses patch specifies the file's relative pathname in the Index:
 * >     line but "old" (2.2.5R) patch interprets them bogusly (whatever
 * >     that means) and tries to patch the wrong file
 * > 
 * > (2) ncurses patch has correct relative pathnames in ***/--- lines and
 * >     Index: lines that is not the relative pathname of the file in
 * >     question, so "old" patch tries to patch the file specified in
 * >     "Index:" and fails
 * 
 * Not first and not second :-)
 * 
 * Here is typical header from ncurses patch:
 * 
 * Index: src/Makefile
 * *** 1997NNN/src/Makefile
 * *** 1997XXX/src/Makefile
 * 
 * Automatic system calls 'patch -p1'

That is (2), quite clearly.  (Unless patch used to ignore the -pN
arguments for "Index:" lines.)

 * > Can you make a filter like that work reliably?  And are we going to
 * > call it "patch"?
 * 
 * I already think about alternate /usr/bin/broken_patch especially for
 * ports system, but even in this case it should be NOT be called for 3-rd
 * party "distributed" patches, standard /usr/bin/patch should be called
 * in such cases.

What about "cvs diff -u" patches submitted from 2.2.5R users?

I think the best thing to do is to install two version of patches
until 2.2.6 so committers running -stable don't have to dig out the
patch binary from the CD to deal with PR submissions.  How about
/usr/bin/opatch for the old behavior and /usr/bin/patch for the one
with the "fix"?  (This is not for bsd.port.mk use, so long names like
"broken_patch" is not practical.)

 * It not helps to yell loud if nobody listen, trust me.

I thought the purpose of yelling is so that nobody wants to argue
anymore. :)

Really, this is getting disgusting.  If I haven't invested so much of
my time into FreeBSD, I would have walked away from the project many
months ago.

 * It seems I have bad Karma to explain in details what happens with patch to
 * each and every core team member separately, because others not read
 * this discussion until something not works as expected for them.

Maybe it's worth pointing out that all the recent flame wars have been
caused by someone committing something controversial without
discussing it first.  When things break, people tend to get angry.  A
bunch of angry people is a good source for fire.  (Although in this
case, it seems the fire was mainly coming from the other direction.)

 * Anybody can argue in the case when it is unclear is it a bug or not,
 * but when it is definitely a bug, there is no arguments possible by
 * the definition of bug word.

We have been shipping patch (which has been consistent with *our*
patch(1) too) and a matching cvs for awhile.  Some people think being
incompatible with our own most recent release is just about as bad if
we don't make the transition smooth.

Satoshi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801210101.RAA19809>