From owner-svn-src-all@FreeBSD.ORG Fri May 23 17:26:42 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E215528A; Fri, 23 May 2014 17:26:42 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D5CEA23FF; Fri, 23 May 2014 17:26:41 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id x12so5083622wgg.21 for ; Fri, 23 May 2014 10:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=JvEeBlA+wY26T4d0GRA7ROfXklBw58pUIPGsxFjXbEc=; b=Lw/pKgyPDnS3G//xTbqfq7+GtAx/spZRc5wbbx8EqTyLzXrQ990B/QKGqs7cXThkMT Eveqq9ralgTyfREYKNIH2Hjpahi5THvUIahln2OZZWJe0dVSNQiNBytvWsLq8rLha3CK yEPxBV8JGbTGwAPVr9dpMCllElEqchOiDLvSACKp/AB8qNgcHVJmsqmtHDYEaaolC61i /6+Ahuplt8gmgffRhTfUT80+sfo0AZ7L8hPBeWTHU+cHXacHr22h1C8Er9sVWThJZF2u YgOXSUXLQmLYIilel4NdvfZ1vpaAfJunQg9+3hSipfBW5MFramkE9Auhs6/xXQufiHS2 Cn+Q== X-Received: by 10.194.1.164 with SMTP id 4mr5501677wjn.17.1400866000065; Fri, 23 May 2014 10:26:40 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id k2sm4645344wjq.20.2014.05.23.10.26.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 May 2014 10:26:39 -0700 (PDT) Sender: Baptiste Daroussin Date: Fri, 23 May 2014 19:26:36 +0200 From: Baptiste Daroussin To: Nathan Whitehorn Subject: Re: svn commit: r266553 - head/release/scripts Message-ID: <20140523172636.GK72340@ivaldir.etoilebsd.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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vbzKE9fGfpHIBC6T" Content-Disposition: inline In-Reply-To: <537F8153.7080808@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) 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 17:26:43 -0000 --vbzKE9fGfpHIBC6T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 23, 2014 at 10:11:47AM -0700, Nathan Whitehorn wrote: >=20 > 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 t= o just > >>>>>> be uname -p? > >>>>>> -Nathan > >>>>> Keeping asking won't make it happen, I have explained a large numbe= r 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 th= at 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 stor= ed at the > >>>>> very end of this todo. > >>>>> > >>>>> regards, > >>>>> Bapt > >>>> I'm happy to do the work, and have volunteered now many times. If un= ame > >>>> -p does not describe the ABI fully, then uname -p needs changes on t= he > >>>> 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 >=20 > We don't provide packages for ARM. Also, no platforms have defaulted to= =20 > OABI for a very long time. Not making a distinction was a deliberate=20 > decision of the ARM group, since it was meant to be a clean switchover. >=20 > >>> - The different float abi (even if only one is supported for now othe= rs 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? >=20 > That would be armv6hfeb, I assume, if FreeBSD actually supported=20 > big-endian ARMv6 at all, which it doesn't. >=20 > >> These all already exist. > >> > >>> the extras flexibilit is being able to say this binary do support fre= ebsd i386 > >>> and amd64 in one key, freebsd:9:x86:*, or or all arches freebsd:10:* > >>> > > arm was en example what about mips? >=20 > The same. There is mips64el, mipsel, mips, mips64, etc. that go through= =20 > all possible combinations. This is true for all platforms and has been=20 > for ages. There was a brief period (2007-2010, I think) where some=20 > Tier-3 embedded platforms didn't have enough options, but that era was=20 > obscure and is long past. >=20 > >> 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 w= hich means > > in a couple of years >=20 > Why does it mean that? That doesn't make sense. A couple of symlinks on= =20 > the FTP server ensure compatibility. For the sysctl, it has been merged= =20 > all the back to 7. So We can switch after 8.4 death which is a good news (except if you say th= at it is in 8.4) >=20 > > And it defeats cross installation (which is the reason why the ABI supp= orted is > > read from a binary and not from kernel) >=20 > 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. >=20 > > and last thing is the current build packages should just work meaning t= hat we > > would need to have a kind of mapping table >=20 > Sure, as a compat measure. No reason to lock it in forever. You could=20 > also detect old-style strings with a warning and install them=20 > unconditionally. It's not a big deal. sure but one has to write it :) > -nathan >=20 regards, Bapt --vbzKE9fGfpHIBC6T Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlN/hMwACgkQ8kTtMUmk6Ex9mgCbBk7yesPgm0JNLT9LUkA+09pz UdYAnjPMSDStELEef3/zmXWGkDs0iV6G =Hh5Z -----END PGP SIGNATURE----- --vbzKE9fGfpHIBC6T--