svn commit: r266553 - head/release/scripts

[Bryan Drewery]

On 2014-05-23 18:15, Nathan Whitehorn wrote:
> On 05/23/14 14: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.
> 
> No, I'm not. Suppose you make an amd64 jail and install an i386
> package into it. That's fine (or is potentially fine anyway). But
> there is no way to be sure since whether it's fine or not depends on
> the kernel you happen to run.
> 
>>> 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?
> 
> Yes, of course. I think it's part of POSIX. The GNU and OS X versions
> of uname have it anyway.
> 
> I'm really quite mystified why you're so insistent on having your own
> private ABI identifier strings. If you're really set on this, I of
> course can't make you change. As you note, pkg is not something that
> lives in FreeBSD and I have no power to change it. And, from this
> conversation, I now strongly suspect that if I did put in the work to
> fix this, my patch would be ignored or rejected. But it does mystify
> me.
> -Nathan

Well "highly questioning the design choice" is quite a rude attitude.
It's not a good way to collaborate.

-- 
Regards,
Bryan Drewery