From owner-svn-src-all@FreeBSD.ORG Fri May 23 16:38:17 2014 Return-Path: Delivered-To: svn-src-all@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 BD5E24AB; Fri, 23 May 2014 16:38:17 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 5BBFC2F08; Fri, 23 May 2014 16:38:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 6C5C33806A; Fri, 23 May 2014 11:38:16 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id GRXOqTHxXdho; Fri, 23 May 2014 11:38:16 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id B705338064; Fri, 23 May 2014 11:38:15 -0500 (CDT) Message-ID: <537F7976.3060705@freebsd.org> Date: Fri, 23 May 2014 09:38:14 -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: Baptiste Daroussin 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> In-Reply-To: <20140523162020.GG72340@ivaldir.etoilebsd.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, Glen Barber , svn-src-all@FreeBSD.org, src-committers@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 16:38:17 -0000 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. > - 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) 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:* > 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. -Nathan