From owner-freebsd-ports Tue Jan 20 17:29:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA26911 for freebsd-ports-outgoing; Tue, 20 Jan 1998 17:29:38 -0800 (PST) (envelope-from owner-freebsd-ports@FreeBSD.ORG) Received: from baloon.mimi.com (sjx-ca126-30.ix.netcom.com [207.92.177.222]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA26889; Tue, 20 Jan 1998 17:29:19 -0800 (PST) (envelope-from asami@vader.cs.berkeley.edu) Received: (from asami@localhost) by baloon.mimi.com (8.8.8/8.8.8) id RAA19809; Tue, 20 Jan 1998 17:01:45 -0800 (PST) (envelope-from asami) Date: Tue, 20 Jan 1998 17:01:45 -0800 (PST) Message-Id: <199801210101.RAA19809@baloon.mimi.com> To: ache@nagual.pp.ru CC: peter@netplex.com.au, perhaps@yes.no, gpalmer@FreeBSD.ORG, ports@FreeBSD.ORG, committers@FreeBSD.ORG In-reply-to: (message from =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= on Tue, 20 Jan 1998 15:54:45 +0300 (MSK)) Subject: Re: amanda port, empty PATCH_STRIP= lines causes trouble From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * > (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