svn commit: r266553 - head/release/scripts

[Bryan Drewery]

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?

> -Nathan

-- 
Regards,
Bryan Drewery