svn commit: r266553 - head/release/scripts

Sat May 24 01:24:53 UTC 2014

On 2014-05-23 17:34, Bryan Drewery wrote:
> On 2014-05-23 16:19, Nathan Whitehorn wrote:
>> On 05/23/14 12:27, Baptiste Daroussin wrote:
>>> On Fri, May 23, 2014 at 12:01:08PM -0700, Nathan Whitehorn wrote:
>>>> On 05/23/14 10:26, Baptiste Daroussin wrote:
>>>>> On Fri, May 23, 2014 at 10:11:47AM -0700, 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.
>>>>> So We can switch after 8.4 death which is a good news (except if 
>>>>> you say that it
>>>>> is in 8.4)
>>>> It means we can do it now. Very few people install i386 packages on
>>>> amd64 anyway. It means people with very old releases on old branches
>>>> might face a warning in an unusual situation. Not a big deal. Since 
>>>> we
>>>> only provide i386 and amd64 packages anyway, this is also a trivial
>>>> special case if you really want that.
>>>> 
>>>>>>> And it defeats cross installation (which is the reason why the 
>>>>>>> ABI supported is
>>>>>>> read from a binary and not from kernel)
>>>>>> No. That's the point of the sysctl.
>>>>> I'm speaking of installing packages in a arm chroot on a amd64 host 
>>>>> I will need
>>>>> to know what arch could be supported by the "content" of the 
>>>>> chroot.
>>>> uname -p in the chroot (I guess this is with qemu) should return the
>>>> right answer, just as it does with an i386 chroot. If it doesn't,
>>>> something is broken in the qemu user mode support.
>>> nope that is not with qemu it is basically cross buildworld, install 
>>> in a
>>> destdir, install packages in that destdir which is a very common 
>>> usage that a
>>> lot do expect to work
>>> 
>> 
>> Knowing a priori which architectures are "supported" by a chroot based
>> on ELF type of /bin/sh doesn't even work. How do you know what kernel
>> will be running in there and how it will be configured? You don't.
>> IA64 can -- sometimes -- run i386 binaries, for example. amd64 may or
>> may not be able to run i386, depending on kernel options.
>> 
> 
> You're assuming that you would only use a chroot to RUN things. This is
> also useful for building images. Install a world into a chroot, run
> pkg -c install whatever and it picks the right ABI. Just an example.
> 
>> In any case, I wouldn't really characterize this situation as "common"
>> in any sense -- and I don't even see why it applies to this
>> discussion. Whatever logic calculates your own private version of
>> architecture strings can calculate the correct ones. Allowing it to
>> ignore the architecture optionally, just like you how you already have
>> to add flags to install in a chroot, would also work. Lots of things
>> like that. This issue is basically wholly unrelated to whether you use
>> normal architecture strings or not.
>> 
>> I'm perfectly happy to write 100% of the code to enable pkg to use the
>> same architecture strings that the rest of the operating system uses.
>> Having private ones is just a recipe for confusion. From this
>> discussion, there don't seem to be any actually existing reasons why
>> MACHINE_ARCH doesn't work for this.
> 
> pkg is *not* FreeBSD-specific. Is MACHINE_ARCH portable?
> 

I don't think it matters whether MACHINE_ARCH is portable. FreeBSD amd64 
binaries are not going to run on Linux x86_64, for example. Setting pkg 
ABI to something like freebsd:arm:armv6hf or freebsd:amd64:amd64 is 
specific enough, and could allow installation if the last triplet is in 
kern.supported_archs. Then you can have linux:fruit:banana packages that 
will correctly not install on freebsd:amd64:amd64. The current mapping 
is not intuitive.

- Nikolai Lifanov