svn commit: r343559 - head/net-p2p/litecoin

[David Chisnall]

On 10 Feb 2014, at 10:12, Baptiste Daroussin <bapt at 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 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+=	freebsd:PR12345
INSTALL_BLOCKED_BY+=	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+=	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