From owner-freebsd-ports Sun Jan 18 21:20:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA25381 for freebsd-ports-outgoing; Sun, 18 Jan 1998 21:20:45 -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 VAA25369; Sun, 18 Jan 1998 21:20:34 -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 IAA16340; Mon, 19 Jan 1998 08:20:14 +0300 (MSK) (envelope-from ache) Date: Mon, 19 Jan 1998 08:20:10 +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: <199801190104.RAA09386@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 Sun, 18 Jan 1998, Satoshi Asami wrote: > * Lets consider -stable you care about. If both CVS diff change and patch > * "unfix" will be backed out, FreeBSD patch will be unable to handle > * properly non-FreeBSD generated patches. The first reason of "unfixing" was > * that standard ncurses patches set applies cleanly on all systems excepting > * FreeBSD (which have abnormal "fixed" patch). Ncurses patches set is only > * bug trigger and it seems better not wait until another one comes in. > > That's why Peter said you can make a port. What patch other than Is people intended to misintepretate what I write? > * Lets consider -stable you care about. If both CVS diff change and patch > * Lets consider -stable you care about. If both CVS diff change and patch > * Lets consider -stable you care about. If both CVS diff change and patch > * Lets consider -stable you care about. If both CVS diff change and patch > * Lets consider -stable you care about. If both CVS diff change and patch How many times I need to repeat? I _not_ talk here (yet) about new patch in -current, I talk about -stable patch "fix" which is _essential_ bug. > ncurses have you encountered that didn't work with the old patch? On > the other hand, are you aware how many patches now don't work because > of the patch "fix"? > Just because ncurses generates bogus Index: lines (whether they are ncurses generates ABSOLOTELY 100% RIGHT Index: lines, "fixed" FreeBSD patch interpretate them bogusly. With old patch nobody can trust its results anymore, if Index: lines are here, independently of ncurses in particular example. > ignored by "patch" or not) is no reason to break compatibality with > our own releases and installed user base. You already let compatibility be broken but left this "fix" sneak in the patch. Then patch becomes _incompatible_ with old FreeBSD patches (and other world), but nobody cares! > * FreeBSD patch bug (as result of "fixing" it instead of CVS) is sometimes > * stealthy and hardly detected which can cause serious undetected damage for > * anyone who apply some non-FreeBSD generated patch. Of course, I already > * write that some time ago... > > And why doesn't the same argument apply to patches submitted by people > running 2.2.5R? PLEASE READ! PLEASE READ! ----------------------------------------- If CVS from 2.2.5R is broken to generate wrong diffs, this issue should be handled somewhere else instead of breaking patch then!. You left CVS bug be introduced, then left patch be broken to compensate it. Instead of broke programs in chain mode we must return to the start and think probably about some filter which detects wrong CVS diffs from 2.2.5R. This filter is easy - just compare Index: line and ---/*** lines, and if Index: line is longer, replace ---/**** lines on the fly or call _special_ version of patch (not default one!) to handle them. Now something about -current new patch, I already write it and repeat until people start to read me: > I think situation with -current will be more clear when this issue will > be resolved first somehow. > I think situation with -current will be more clear when this issue will > be resolved first somehow. > I think situation with -current will be more clear when this issue will > be resolved first somehow. > I think situation with -current will be more clear when this issue will > be resolved first somehow. 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. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/