svn commit: r266553 - head/release/scripts

Warner Losh imp at
Fri May 23 23:29:49 UTC 2014

On May 23, 2014, at 10:20 AM, Baptiste Daroussin <bapt at> 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
> - The different float abi (even if only one is supported for now others are
>  being worked on)
> - little endian vs big endian

All of those are encoded in the MACHINE_ARCH + freebsd version, no exceptions
on supported architectures that are tier 2 or higher. This seems like a weak reason.

> 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:*

Will there be a program to convert this new, special invention to the standard
that we’ve used for the past 20 years? If you need the flexibility, which I’m not
entirely sure I’ve seen a good use case for. When would you have a x86 binary package? Wouldn’t it be either i386 or amd64?


More information about the svn-src-head mailing list