svn commit: r266553 - head/release/scripts

Sat May 24 02:38:59 UTC 2014

On 05/23/14 19:33, Bryan Drewery wrote:
> 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.
>

Apologies. I do wish you would consider the points made regardless of 
rudeness, however.
-Nathan