From owner-svn-ports-head@FreeBSD.ORG Mon Feb 10 16:22:27 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 10775536; Mon, 10 Feb 2014 16:22:27 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D12AD1CBF; Mon, 10 Feb 2014 16:22:25 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id l18so4393053wgh.29 for ; Mon, 10 Feb 2014 08:22:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=pcOj83+MP03quWropwaFRRIQTtpJ0dgsq54S7fsBcdI=; b=C+NkMmwOXfcvKK9QcEX34NWbsNKKk9G2jlP/igEnjhV7wTRqVRICT5FeFca798W4UV 9KKuYHtivPTNZNthTyz9ZSAf26MK/O1StnQJu0zt5Hrkb+h/VB5vqLIZ5iiYEfSSYw2W uQTKgqCudBiW90D/hE12hsEbcKp+5w5cJkougqviDoQ2GLUjwTu4WFBRf40slWBTCdyT 0d0LE3MuByc/4+wmAEp4wKVbfnyB3AAkWisx0FxwXRg6mNvLN7gygKr0dO17Jg9/xASu GJfrRn0eP4bQdzGmGxzSAG/mOr6Uvfh0WVNP4Sf/KC7gsQENdF5hsxW66q82sJATcMQq 5Shw== X-Received: by 10.194.175.66 with SMTP id by2mr2214985wjc.59.1392049344269; Mon, 10 Feb 2014 08:22:24 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id ua8sm36581422wjc.4.2014.02.10.08.22.21 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 10 Feb 2014 08:22:22 -0800 (PST) Sender: Baptiste Daroussin Date: Mon, 10 Feb 2014 17:22:20 +0100 From: Baptiste Daroussin To: David Chisnall Subject: Re: svn commit: r343559 - head/net-p2p/litecoin Message-ID: <20140210162219.GE80056@ithaqua.etoilebsd.net> References: <201402092329.s19NTHiq089517@svn.freebsd.org> <20140210011718.GA79272@mouf.net> <20140210075232.GU80056@ithaqua.etoilebsd.net> <20140210101243.GX80056@ithaqua.etoilebsd.net> <5293CBB5-D3D8-4184-B7E0-DC632E906C39@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wwSkEpePV3aFlXly" Content-Disposition: inline In-Reply-To: <5293CBB5-D3D8-4184-B7E0-DC632E906C39@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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 16:22:27 -0000 --wwSkEpePV3aFlXly Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 10, 2014 at 02:46:52PM +0000, David Chisnall wrote: > On 10 Feb 2014, at 10:12, Baptiste Daroussin wrote: >=20 > > If one has a nice idea to centralize those informations I'm all about i= t, 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. >=20 > It would be good to have some discussion about what is actually required.= I think that these break down into several broad categories: >=20 > Bug Fixes > --------- >=20 > You want to be able to say 'this port depends on this bug fix being appli= ed to the base system'. These are all OS-specific (i.e. a FreeBSD bug, eve= n 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 an= d 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: >=20 > BUILD_BLOCKED_BY+=3D freebsd:PR12345 > INSTALL_BLOCKED_BY+=3D freebsd:PR54321 >=20 > The prefixes in this would reference a per-architecture file and be ignor= ed 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 fi= xes 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 ex= pressive. >=20 >=20 > System Features > --------------- >=20 > Different from features required to build / run, we have base system feat= ures that enable extra optional functionality. In this case, we may want t= o add another port dependency if something is not in the base system, or en= able 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-platfo= rm-version) files indicating things that are provided by the base system, f= alling back to using ports or providing nothing when they are not. >=20 > Moved Symbols > ------------- >=20 > When some functionality is moved around, you need to update link lines an= d so on. For example, moving libiconv and libexecinfo into libc in FreeBSD= 10. Here, you want to be able to say something like: >=20 > USES+=3D execinfo >=20 > 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: >=20 > - 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 em= pty) >=20 > What have I missed? I do like the principle, what about now, still I don't know yet how we can implement that. regards, Bapt --wwSkEpePV3aFlXly Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iEYEARECAAYFAlL4/LsACgkQ8kTtMUmk6EwtYgCfSg9ZBOlJZiv/h2yix8tVsACp Xg0AniZXZuzfQ7PGqaVNvgW9FF50a1XA =FZbD -----END PGP SIGNATURE----- --wwSkEpePV3aFlXly--