From owner-svn-ports-all@FreeBSD.ORG Mon Feb 10 17:11:50 2014 Return-Path: Delivered-To: svn-ports-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27FBD8AF; Mon, 10 Feb 2014 17:11:50 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BE419125F; Mon, 10 Feb 2014 17:11:48 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id f8so3054456wiw.1 for ; Mon, 10 Feb 2014 09:11:47 -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=wFffKnASbYLJqAo1nREUCbUYjGKNEm0AfyfBwH8GNok=; b=zl7hH3NgN3zdDOYu3L21SBv2q+1sqzTWmEIx07vlk0bXdn5iHA+T6p5HnluvaFxTb8 pmVvObPaSsk1/RL++yWq//3G+m2wzu3sZOGS6cnNP5j6jsRDYZZbGlu9hR5GqM7ispGG eOtQNy7MSAI1mZn3c7u99E1dvbYuLEHP3oSC2DrheFciUGQfqNIpTE43qfUUEd62HSCw 1nR0xJW+iDI9lN/IjycwMrF3SPpcCAuZOmELlCdta/12P7EiwRDZ6SpmfUA298Z7VBa0 UHxjO6uZpsgcxVj5TN89W/7cAZ2QR7lMKQBbzzm2P588zUITWNgspsBy3Ym8mRriXyH6 rxAA== X-Received: by 10.194.77.7 with SMTP id o7mr22725814wjw.35.1392052307075; Mon, 10 Feb 2014 09:11:47 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id n3sm38183655wix.10.2014.02.10.09.11.43 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 10 Feb 2014 09:11:44 -0800 (PST) Sender: Baptiste Daroussin Date: Mon, 10 Feb 2014 18:11:42 +0100 From: Baptiste Daroussin To: Matthew Seaman Subject: Re: svn commit: r343559 - head/net-p2p/litecoin Message-ID: <20140210171142.GF80056@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> <20140210162219.GE80056@ithaqua.etoilebsd.net> <52F906EE.5080100@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H4Dtu32JQD1K2gM0" Content-Disposition: inline In-Reply-To: <52F906EE.5080100@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 , David Chisnall , ports-committers@FreeBSD.org X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 17:11:50 -0000 --H4Dtu32JQD1K2gM0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 10, 2014 at 05:05:50PM +0000, Matthew Seaman wrote: > On 10/02/2014 16:22, Baptiste Daroussin wrote: > > On Mon, Feb 10, 2014 at 02:46:52PM +0000, David Chisnall wrote: > >> 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. > >>> > >>> May that be OPSYS and/or OSVERSION both requires loading too many tim= es bsd.*.mk > >>> which is not good, looking forward for propositions. > >> > >> It would be good to have some discussion about what is actually requir= ed. 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 ap= plied 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 ig= nored if it didn't match the target system name. The second bit would trig= ger a BROKEN warning if it were in the build part, or be added to the packa= ge 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 f= eatures that enable extra optional functionality. In this case, we may wan= t 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 v= ia the existing USES framework, but with a set of per-platform (and per-pla= tform-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 Free= BSD 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 platfo= rms where it is separate and then have some variables set that you can chec= k, giving: > >> > >> - The path of the headers and libraries (for passing to configure scri= pts and so on) > >> - The linker commands needed to link (either -Lsomething -lexecinfo or= empty) > >> > >> What have I missed? > >=20 > > I do like the principle, what about now, still I don't know yet how we = can > > implement that. >=20 > It sounds a lot like the generic PROVIDES / REQUIRES /CONFLICTS stuff we > were talking about in the context of pkg(8). We'd have to do something > like invent a fake 'base system' package to record the capabilities > provided by the base system, which would sort out people using binary > packages pretty well. Applying this sort of logic at build time is > another question. >=20 Exactly except that base system means nothing :), so creating that sort of packages is rather complex to represent non default built base system. regards, Bapt --H4Dtu32JQD1K2gM0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iEYEARECAAYFAlL5CE4ACgkQ8kTtMUmk6EyOhgCfU37nJrKzKRbhCOa22EogZGgJ LhwAoKkdDzrG2up3DEhJEJ48D60eg3oD =cM6j -----END PGP SIGNATURE----- --H4Dtu32JQD1K2gM0--