Date: Fri, 23 May 2014 11:37:54 -0700 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Bryan Drewery <bdrewery@freebsd.org> Cc: svn-src-head@freebsd.org, Baptiste Daroussin <bapt@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r266553 - head/release/scripts Message-ID: <537F9582.4060400@freebsd.org> In-Reply-To: <0087791e401a70e5224e8dc2253b4e40@shatow.net> References: <201405221922.s4MJM4Y9025265@svn.freebsd.org> <537F6706.6070509@freebsd.org> <20140523153619.GF72340@ivaldir.etoilebsd.net> <537F6EBC.3080008@freebsd.org> <20140523162020.GG72340@ivaldir.etoilebsd.net> <537F7976.3060705@freebsd.org> <20140523164521.GH72340@ivaldir.etoilebsd.net> <537F8153.7080808@freebsd.org> <0087791e401a70e5224e8dc2253b4e40@shatow.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/23/14 10:24, Bryan Drewery wrote: > On 2014-05-23 12:11, 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. > > Symlinks are irrelevant for pkg. It may fetch based on ABI in the URL, > but once it opens the package it also compares the ABI from the package > and repository to the ABI of /bin/sh on the system. So the symlink > wouldn't > help. That is a highly questionable design choice. Why not just check MACHINE_ARCH? In any case, packages only exist for i386 and amd64 in the wild in a supported way. Those two can be special cased for compatibility in about two lines of code if you're worried about this. -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?537F9582.4060400>