From owner-freebsd-ports Tue Jan 20 04:55:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA03130 for freebsd-ports-outgoing; Tue, 20 Jan 1998 04:55:05 -0800 (PST) (envelope-from owner-freebsd-ports@FreeBSD.ORG) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA03125; Tue, 20 Jan 1998 04:55:01 -0800 (PST) (envelope-from ache@lsd.relcom.eu.net) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.8/8.8.8) id PAA24811; Tue, 20 Jan 1998 15:54:48 +0300 (MSK) (envelope-from ache) Date: Tue, 20 Jan 1998 15:54:45 +0300 (MSK) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: Satoshi Asami 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 In-Reply-To: <199801201235.EAA18344@baloon.mimi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 20 Jan 1998, Satoshi Asami wrote: > (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' In standard GNU patch (any version) 1997NNN is stripped producing src/Makefile, in "fixed" FreeBSD patch src is stripped producing Makefile, and most unpleasant thing is that Makefile exist too and is very similar with src/Makefile, i.e. Makefile was successfully patched instead of src/Makefile! > 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. > > * I start to fear where FreeBSD project goes. The thigs like 1) easily > * sneaking hacks (causing essential bug) together with 2) unwiling to remove > * them argumenting with functionality reasons are clear signs of > * degradation. I ever not mention that nobody seems to read even the first > * line of my message. > > I'm starting to fear too. I really don't like the current atmosphere > in which it seems people who yell louder always get their way because > others just get too annoyed to argue. :< It not helps to yell loud if nobody listen, trust me. 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. 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. "because it breaks" is not an argument, some another ways must be found to compensate what is broken, not backing out bugfix. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/