From owner-freebsd-ports@FreeBSD.ORG Sun Jan 22 08:13:47 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 239091065672 for ; Sun, 22 Jan 2012 08:13:47 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id DFC438FC12 for ; Sun, 22 Jan 2012 08:13:46 +0000 (UTC) Received: by iagz16 with SMTP id z16so4762989iag.13 for ; Sun, 22 Jan 2012 00:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=bCkspS7xTexCawwAk3nNnoEQH3qHdPkjFLWMoTvRnCE=; b=PiO8UDPMoZ7RLLcgj0sQ8FSRRiRswwccTeib623+HoG+P5Z9eJMSPTJTPnw5nnIOLW tQXl2CCebqFf3qp/0ypWTJMQrhlQBR7thNWECO8KIsgTBGUU2OnnKpB6WidLSTNeb4Fv 07NcGZe2PvwmJmuB5L0NQ+R6LfIpUwrG8HJCY= Received: by 10.42.145.131 with SMTP id f3mr4747792icv.8.1327220026300; Sun, 22 Jan 2012 00:13:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.70.15 with HTTP; Sun, 22 Jan 2012 00:13:15 -0800 (PST) In-Reply-To: <20120121204614.GH4729@lonesome.com> References: <4F177264.3090708@freebsd.org> <4F17DB1C.6080503@infracaninophile.co.uk> <4F193FD5.8070208@infracaninophile.co.uk> <20120121204614.GH4729@lonesome.com> From: Chris Rees Date: Sun, 22 Jan 2012 08:13:15 +0000 Message-ID: To: Mark Linimon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-ports@freebsd.org Subject: Re: NOT_FOR_ARCHS considered harmful [was: with the cvs history? trying to help INDEX builds.] 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: Sun, 22 Jan 2012 08:13:47 -0000 On 21 Jan 2012 20:46, "Mark Linimon" wrote: > > On Fri, Jan 20, 2012 at 10:20:05AM +0000, Matthew Seaman wrote: > > Actually I take your point, that it should be possible to distinguish > > between ports that permanently won't work on some architectures by > > design, and ports that temporarily don't work because of mistakes or > > broken dependencies or so forth, and that are expected to be fixed > > sooner rather than later. > > There's a secondary problem which I keep meaning to write up a rant > on. =A0This thread seems as good a place as any. > > Warning: the following is only my own opinion, not portmgr's. > > We made a design mistake by allowing in NOT_FOR_ARCHS as an alternative > to ONLY_FOR_ARCHS. =A0This has always been a shortcut to say "doesn't > build on !(amd64!i386)". =A0As long as the archs were (alpha|amd64|i386| > sparc64) this was merely annoying. > > The problem comes when we start up package builds on new archs. =A0 The > primary utility of package builds for tier-2s has arguably been to QA > whether the ports build at all. =A0The secondary utility, in order: > > =A0- test that the arch's srcbase has't regressed to the point where it's > =A0 too unstable to build packages > > =A0- flag ports (and infrastructure) with bad assumptions about wordlengt= h > =A0 and endianness > > =A0- create usable packages (really, only the most fundamental ports will > =A0 have packages that are timely, due to the > 1 month cycle times) > > In general, I claim if a port already has some kind of NOT_FOR_ARCH > entry, it's unlikely to build on a new arch. =A0This was clearly demonstr= ated > a couple of years ago when I first started powerpc builds once we had a > machine donated (note: powerpc =3D 32-bit). =A0The errors were correlated= to > sparc64, but only roughly. > > sparc64 builds tend to trip up on the following, in order of which I > think we should care: > > =A0- 64-bit issues (which have a high correlation to amd64 build failures= ), > > =A0- lack of arch-specific build stanzas (which have a high correlation t= o > =A0 powerpc), > > =A0- endianness issues. > > The powerpc build also pointed out that many ports assumed that 32bit <> = i386. > On occasion, I fix notable occurences of this (e.g. python). > > So, why does this matter? =A0Surely our sparc64 and powerpc/Mac userbases > are tiny. > > The reason to do this work is that there is demand for arm and mips build= s > for embedded systems[1], and once these are turned on, we're going to hav= e > a bazillion build errors to sort through. > > To the extent that our first attempts include only ports that don't have > the NOT_FOR stanzas, IMHO we're going to make more progress more quickly. > > Now, for mips, only the "fundamental" ports are ever going to matter, > since there are no viable mips desktops to worry about. =A0But, for > embedded, getting a subset of things in net/ and sysutils/ (and to > some extent things like lang/perl) is going to be useful -- again, not > so much for uploadable packages, but to ensure buildability when vendors > try to use these in their products. > > (I'm told that people are speculating about running desktop stuff on > native arm, so that's why I picked mips for the use-case. =A0I have no > idea if that's anything but blue-sky.) > > So IMHO we should do a sweep: > > =A0- move all the true cases of NOT_FOR_ARCHS to ONLY_FOR_ARCHS > > =A0- move all the false cases of NOT_FOR_ARCHS to BROKEN > > and then drop support for NOT_FOR_ARCHS. > > If anyone is interested in coming up with patches, I'll do the -exp > run (on amd64 :-) ) to prove that there are no regressions on that > arch at least. > > Finally, for those willing to investigate how messed-up the metadata > currently are, pull up the following page: > > =A0http://pointyhat.freebsd.org/errorlogs/packagestats.html > > You'll find a column marked "skipped". =A0That contains URLs to files > called "duds.verbose" for each buildenv. =A0This file is the output of > 'make ignorelist-verbose' called from the top of the tree. > > The reason that we decided to archive these per-pointyhat-run is so > that you can tell _exactly_ why pointyhat believed that it did not have > to try to build that package at that exact point in time. =A0In the past, > you had to impute it from whatever the state of the tree was. =A0Since > the tree evolves so quickly, it was impossible to tell. =A0(There are > also a very small handful of degenerate cases where things don't > build on pointyhat due to its build environment. =A0I've worked on gettin= g > these down to < 10 over the past few years.) > > tl;dr: I want to switch the default assumption we're making. > > IMHO when new ports come into the tree, we should make our default > assumption that we will try to build them on amd64 and i386. =A0For cases > that this does not hold, we consider this Bad and committer-must-fix. > For the tier-2s, we shift the default assumption to "only set it to > buildable once it has been shown to be so". =A0So, the burden of proof > shifts the other way: to a user of a tier-2 to claim "I tried this and > it works", rather than portmgr saying "we tried this and it doesn't work"= . > > (Of course, for things like p5-* it doesn't really matter; if perl > builds, to a first approximation they'll build as well. =A0I'm talking > about the things like biology/, deskutils/, games/, math/, science, > x11*/, and so forth.) > > What do people think? > I think we'll end up with a FreeBSD that only works on amd64 and IA-32... Chris