From owner-svn-src-head@FreeBSD.ORG Fri May 23 18:39:11 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1787F37; Fri, 23 May 2014 18:39:11 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5DA62A66; Fri, 23 May 2014 18:39:11 +0000 (UTC) Received: from zeppelin.tachypleus.net (airbears2-136-152-142-26.AirBears2.Berkeley.EDU [136.152.142.26]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s4NId9qe003340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 23 May 2014 11:39:10 -0700 Message-ID: <537F9582.4060400@freebsd.org> Date: Fri, 23 May 2014 11:37:54 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Bryan Drewery Subject: Re: svn commit: r266553 - head/release/scripts 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> In-Reply-To: <0087791e401a70e5224e8dc2253b4e40@shatow.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;XJtQh6ni4xGzF1MaeQW9yA== M;YDp7h6ni4xGzF1MaeQW9yA== Cc: svn-src-head@freebsd.org, Baptiste Daroussin , src-committers@freebsd.org, svn-src-all@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 18:39:12 -0000 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