From owner-svn-ports-head@FreeBSD.ORG Mon Feb 10 14:47:08 2014 Return-Path: Delivered-To: svn-ports-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A211B76; Mon, 10 Feb 2014 14:47:08 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AEAEE141A; Mon, 10 Feb 2014 14:47:07 +0000 (UTC) Received: from dhcp-172-17-157-204.eduroam.lapwing.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.5) with ESMTP id s1AEkwV2001888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Feb 2014 14:47:00 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: svn commit: r343559 - head/net-p2p/litecoin From: David Chisnall In-Reply-To: <20140210101243.GX80056@ithaqua.etoilebsd.net> Date: Mon, 10 Feb 2014 14:46:52 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <5293CBB5-D3D8-4184-B7E0-DC632E906C39@FreeBSD.org> References: <201402092329.s19NTHiq089517@svn.freebsd.org> <20140210011718.GA79272@mouf.net> <20140210075232.GU80056@ithaqua.etoilebsd.net> <20140210101243.GX80056@ithaqua.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1827) Cc: svn-ports-head@FreeBSD.org, Steve Wills , svn-ports-all@FreeBSD.org, John Marino , ports-committers@FreeBSD.org X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 14:47:08 -0000 On 10 Feb 2014, at 10:12, Baptiste Daroussin wrote: > If one has a nice idea to centralize those informations I'm all about = it, by > nice idea I mean format and implementation. >=20 > May that be OPSYS and/or OSVERSION both requires loading too many = times bsd.*.mk > which is not good, looking forward for propositions. It would be good to have some discussion about what is actually = required. I think that these break down into several broad categories: Bug Fixes --------- You want to be able to say 'this port depends on this bug fix being = applied to the base system'. These are all OS-specific (i.e. a FreeBSD = bug, even if it is shared with DBSD will likely have different tracking = for the fix) and fall into two categories: those that prevent the port = from running and those that prevent it from being built. I'd imagine = that we'd want to be able to address these in ports by things like: BUILD_BLOCKED_BY+=3D freebsd:PR12345 INSTALL_BLOCKED_BY+=3D freebsd:PR54321 The prefixes in this would reference a per-architecture file and be = ignored if it didn't match the target system name. The second bit would = trigger a BROKEN warning if it were in the build part, or be added to = the package metadata otherwise. The base system would need to publish a = list of the fixes that had been applied that pkg could check, so this = list would need to be outside of the ports tree, just as = __FreeBSD_version is now, but more expressive. System Features --------------- Different from features required to build / run, we have base system = features that enable extra optional functionality. In this case, we may = want to add another port dependency if something is not in the base = system, or enable an optional feature only when it is. A lot of this = could be made via the existing USES framework, but with a set of = per-platform (and per-platform-version) files indicating things that are = provided by the base system, falling back to using ports or providing = nothing when they are not. Moved Symbols ------------- When some functionality is moved around, you need to update link lines = and so on. For example, moving libiconv and libexecinfo into libc in = FreeBSD 10. Here, you want to be able to say something like: USES+=3D execinfo This should add an explicit dependency on the execinfo port for = platforms where it is separate and then have some variables set that you = can check, giving: - The path of the headers and libraries (for passing to configure = scripts and so on) - The linker commands needed to link (either -Lsomething -lexecinfo or = empty) What have I missed? DAvid