From owner-freebsd-ports Fri Jan 16 17:17:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA14189 for freebsd-ports-outgoing; Fri, 16 Jan 1998 17:17:30 -0800 (PST) (envelope-from owner-freebsd-ports@FreeBSD.ORG) Received: from ppp1545.on.bellglobal.com (ppp1545.on.bellglobal.com [206.172.249.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA14144 for ; Fri, 16 Jan 1998 17:16:58 -0800 (PST) (envelope-from ac199@hwcn.org) Received: from localhost (tim@localhost) by localhost.my.domain (8.8.8/8.8.8) with SMTP id SAA00985; Fri, 16 Jan 1998 18:08:57 -0500 (EST) (envelope-from ac199@hwcn.org) X-Authentication-Warning: localhost.my.domain: tim owned process doing -bs Date: Fri, 16 Jan 1998 18:08:57 -0500 (EST) From: Tim Vanderhoek X-Sender: tim@localhost Reply-To: ac199@hwcn.org To: Satoshi Asami cc: ache@nagual.pp.ru, ports@FreeBSD.ORG Subject: Re: bsd.port.mk patch for review In-Reply-To: <199801160620.WAA02177@bubble.didi.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 Thu, 15 Jan 1998, Satoshi Asami wrote: > * -b works differently between this two versions. > * > * In case you want the same bsd.port.mk in both -current and -stable, > * some trick must be used to detect patch version, maybe > * 'patch --version' call or just simple -current detection, > * or adding PATCHFLAGS to sys.mk, etc. > > We can have different bsd.port.mk for -current and 2.2, but I'd like > to avoid that. Even if the appropriate patch flag is merged into 2.2.5-stable, you'll need to include a patch binary in _all_ future 222upgrade-9#.##.## files. > Yes, we can certainly fix this in bsd.port.mk but I think this just > illustrates that it's patch that really needs to be fixed. Can we > tell POSIX to go fsck itself and make patch work the same on all > versions of FreeBSD? I've always suspected that GNU has the right idea with their POSIX_ME_HARDER. I've not heard a single argument in favour of not always making .orig files. I think that sometimes a history of non-standardization has scared us into over-standardization. There can't be more than one or two application which could ever really depend on the non-creation of .orig files, but the same non-creation could turn into a daily nuisance (or yet-another-dumb-shell-alias). -- tIM...HOEk OPTIMIZATION: the process of using many one-letter variables names hoping that the resultant code will run faster.