Date: Mon, 10 Feb 2014 17:05:50 +0000 From: Matthew Seaman <matthew@FreeBSD.org> To: Baptiste Daroussin <bapt@FreeBSD.org>, David Chisnall <theraven@FreeBSD.org> Cc: svn-ports-head@FreeBSD.org, Steve Wills <swills@FreeBSD.org>, svn-ports-all@FreeBSD.org, John Marino <marino@FreeBSD.org>, ports-committers@FreeBSD.org Subject: Re: svn commit: r343559 - head/net-p2p/litecoin Message-ID: <52F906EE.5080100@FreeBSD.org> In-Reply-To: <20140210162219.GE80056@ithaqua.etoilebsd.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IkFS4n8lIfnqqCqigtAolCh7w1k3oHiV4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 r= unning 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 tr= igger a BROKEN warning if it were in the build part, or be added to the p= ackage 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 wou= ld 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 w= ant 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 b= ase system, falling back to using ports or providing nothing when they ar= e 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 Fr= eeBSD 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 ch= eck, 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. 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. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --IkFS4n8lIfnqqCqigtAolCh7w1k3oHiV4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJS+QbwXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATQqkP/j26DPQWlMiAtHpb24dDj2Jd vUwjHAVEIkYh59JRsHPdHn3PPNhWyDI+4+ZA3JTTTjTrDorAnFLdrVhZt6IKwQBo rLF7hTr4W3bisWjQR9oVb50Zc4ZQGDYHem1USp4IjbgPTmVDe9CS06GFKsxM9J5/ fDtd6+zkn8GMSM44A7d8UDlVE6+bEa+0OKLvKeGa6MWIaXYK5CvWm2boZTVmCFam d4B/hgU/x7qSxCrQfb5EcrCLVRK0XNchg5kcLL8hK2U9Qxg5TQyaMwXfT802hXya fnmiZt8tOthLTIAiRIzrWjhJg6CO1I+WETx94GE9zHcqXDcYrBQm9PyqtXswTQoQ fWfyx6FPoLOzTj6qPN7TWUME7wonWdvIamdQDGpa3rOI6+/I2T+1ayVULZ/xgVUg 2tkouOKeqrnkycUCWgrR3awMAdf+WR02gRg3r796jg3XlmrI9M6wuNU8FW8ZzxjR KcoKRd2iMmsLQU9JNPD5btAlCv+11x4AIe2TXrxkN+bOxionLrW90n/4aM/czEZ3 Oo0WqCFKTJYwWKeaUFQHsZ4smKIJU3YgLXxhioH7/NLDIfFAMG5ca5siTegH41yP 3FyKaIgPw5n2Lk1ZOE0TQqa8YacyiI1KT2p57q81hG7E/ZgbPFgAjiap/4zWrajY SVFSBEtE7BEi6bGonfEg =dqoS -----END PGP SIGNATURE----- --IkFS4n8lIfnqqCqigtAolCh7w1k3oHiV4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52F906EE.5080100>