svn commit: r266553 - head/release/scripts

Nathan Whitehorn nwhitehorn at
Fri May 23 16:38:17 UTC 2014

On 05/23/14 09:20, Baptiste Daroussin wrote:
> On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn wrote:
>> On 05/23/14 08:36, Baptiste Daroussin wrote:
>>> On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn wrote:
>>>> Is there any chance of finally switching the pkg abi identifiers to just
>>>> be uname -p?
>>>> -Nathan
>>> Keeping asking won't make it happen, I have explained a large number of time why it
>>> happened, why it is not easy for compatibility and why uname -p is still not
>>> representing the ABI we do support, and what flexibility we need that the
>>> current string offers to us.
>>> if one is willing to do the work, please be my guess, just dig into the archives
>>> and join the pkg development otherwise: no it won't happen before a while
>>> because we have way too much work on the todo and this item is stored at the
>>> very end of this todo.
>>> regards,
>>> Bapt
>> I'm happy to do the work, and have volunteered now many times. If uname
>> -p does not describe the ABI fully, then uname -p needs changes on the
>> relevant platforms. Which are they? What extra flexibility does the
>> string give you if uname -p describes the ABI completely?
>> -Nathan
> just simple examples in armv6:
> - eabi vs oabi

OABI is almost entirely dead, and will be entirely dead soon.

> - The different float abi (even if only one is supported for now others are
>    being worked on)

armv6 and armv6hf

> - little endian vs big endian

armv6 and armv6eb (though I think armv6eb support in general has been 
removed from the tree, but armeb is still there)

These all already exist.

> the extras flexibilit is being able to say this binary do support freebsd i386
> and amd64 in one key, freebsd:9:x86:*, or or all arches freebsd:10:*

The second one already would work, wouldn't it? Just replacing x86:64 
with amd64 won't change anything. The first has to be outweighed by 
being able to reliably figure out where to fetch from without a lookup 

We also added the kern.supported_archs sysctl last year to all branches 
to enable figuring out which architectures a given running kernel 
supports (e.g. amd64 and i386 on most amd64 systems). This was designed 
specifically to help pkg figure out what packages it can install.

More information about the svn-src-head mailing list