From owner-freebsd-ports@FreeBSD.ORG Thu Aug 18 00:13:05 2005 Return-Path: X-Original-To: ports@freebsd.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C1AA16A41F for ; Thu, 18 Aug 2005 00:13:05 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0C3043D45 for ; Thu, 18 Aug 2005 00:13:04 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j7I0CxZw015930; Wed, 17 Aug 2005 17:12:59 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j7I0CwMj015929; Wed, 17 Aug 2005 17:12:58 -0700 Date: Wed, 17 Aug 2005 17:12:58 -0700 From: Brooks Davis To: Benjamin Lutz Message-ID: <20050818001258.GA14367@odin.ac.hmc.edu> References: <20050817195839.GA22027@odin.ac.hmc.edu> <4303CF35.400@datacomm.ch> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: <4303CF35.400@datacomm.ch> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: Brooks Davis , ports@freebsd.org Subject: Re: prebuild sanity checks X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2005 00:13:05 -0000 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 18, 2005 at 01:58:45AM +0200, Benjamin Lutz wrote: > [...] > > Another option might be a new variable (or variables) that ports that > > tend to break spectacularly and unobviously can set like: > > > > BUILD_DEVS=3D null zero >=20 > As a potential user of such a variable, I wonder how I'm supposed to > figure out which basic system facilities are required by a given piece > of software. Either by having it fail and debugging it or by doing a build with one of the common culprates missing from devfs. In theory it would see that you could do a periodic sweep using the package cluster. > I think the right thing to do here would be to have the software react > more sensibly to such a problem, ie bail out with an error message. In > other words: have the people upstream change their software. In theory yes. In practice, I'm sure a lot of software authors won't care about supporting this environment. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --envbJBWh7q8WU6mo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDA9KKXY6L6fI4GtQRAkp7AKCZvddhs5D+/thKC4Vjo2ooWtpMJQCgk/lo kawvxLOGi0pHI3GblwhTx7M= =JtJH -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo--