svn commit: r266553 - head/release/scripts

Fri May 23 23:15:08 UTC 2014

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