Date: Mon, 10 Feb 2014 14:46:52 +0000 From: David Chisnall <theraven@FreeBSD.org> To: Baptiste Daroussin <bapt@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: <5293CBB5-D3D8-4184-B7E0-DC632E906C39@FreeBSD.org> In-Reply-To: <20140210101243.GX80056@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5293CBB5-D3D8-4184-B7E0-DC632E906C39>