Date: Mon, 10 Feb 2014 18:11:42 +0100 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Matthew Seaman <matthew@FreeBSD.org> Cc: svn-ports-head@FreeBSD.org, Steve Wills <swills@FreeBSD.org>, svn-ports-all@FreeBSD.org, John Marino <marino@FreeBSD.org>, David Chisnall <theraven@FreeBSD.org>, ports-committers@FreeBSD.org Subject: Re: svn commit: r343559 - head/net-p2p/litecoin Message-ID: <20140210171142.GF80056@ithaqua.etoilebsd.net> In-Reply-To: <52F906EE.5080100@FreeBSD.org> References: <201402092329.s19NTHiq089517@svn.freebsd.org> <20140210011718.GA79272@mouf.net> <20140210075232.GU80056@ithaqua.etoilebsd.net> <E8F403F4-EA83-4F71-82E6-9BA27D8D217C@FreeBSD.org> <20140210101243.GX80056@ithaqua.etoilebsd.net> <5293CBB5-D3D8-4184-B7E0-DC632E906C39@FreeBSD.org> <20140210162219.GE80056@ithaqua.etoilebsd.net> <52F906EE.5080100@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <bapt@FreeBSD.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140210171142.GF80056>