svn commit: r266553 - head/release/scripts

Nathan Whitehorn nwhitehorn at
Fri May 23 18:39:12 UTC 2014

On 05/23/14 10:24, Bryan Drewery wrote:
> On 2014-05-23 12:11, Nathan Whitehorn wrote:
>> On 05/23/14 09:45, Baptiste Daroussin wrote:
>>> On Fri, May 23, 2014 at 09:38:14AM -0700, Nathan Whitehorn wrote:
>>>> 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.
>>> Maybe but still for now it is there and pkg has to work now
>> We don't provide packages for ARM. Also, no platforms have defaulted
>> to OABI for a very long time. Not making a distinction was a
>> deliberate decision of the ARM group, since it was meant to be a clean
>> switchover.
>>>>> - 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)
>>> what about combinaison? armv6 + eb + hf?
>> That would be armv6hfeb, I assume, if FreeBSD actually supported
>> big-endian ARMv6 at all, which it doesn't.
>>>> 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:*
>>> arm was en example what about mips?
>> The same. There is mips64el, mipsel, mips, mips64, etc. that go
>> through all possible combinations. This is true for all platforms and
>> has been for ages. There was a brief period (2007-2010, I think) where
>> some Tier-3 embedded platforms didn't have enough options, but that
>> era was obscure and is long past.
>>>> 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
>>>> table.
>>>> 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.
>>> I know, it means that we can switch only when freebsd 8 and 9 are 
>>> EOL which means
>>> in a couple of years
>> Why does it mean that? That doesn't make sense. A couple of symlinks
>> on the FTP server ensure compatibility. For the sysctl, it has been
>> merged all the back to 7.
> Symlinks are irrelevant for pkg. It may fetch based on ABI in the URL,
> but once it opens the package it also compares the ABI from the package
> and repository to the ABI of /bin/sh on the system. So the symlink 
> wouldn't
> help.

That is a highly questionable design choice. Why not just check 

In any case, packages only exist for i386 and amd64 in the wild in a 
supported way. Those two can be special cased for compatibility in about 
two lines of code if you're worried about this.

More information about the svn-src-head mailing list