Date: Fri, 23 May 2014 21:27:01 +0200 From: Baptiste Daroussin <bapt@freebsd.org> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: svn-src-head@freebsd.org, Glen Barber <gjb@freebsd.org>, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r266553 - head/release/scripts Message-ID: <20140523192701.GL72340@ivaldir.etoilebsd.net> In-Reply-To: <537F9AF4.1070502@freebsd.org> 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> <20140523172636.GK72340@ivaldir.etoilebsd.net> <537F9AF4.1070502@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--c8JyeaiReRNoiMDS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 23, 2014 at 12:01:08PM -0700, Nathan Whitehorn wrote: >=20 > 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 num= ber of time why it > >>>>>>> happened, why it is not easy for compatibility and why uname -p i= s 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 in= to 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 st= ored 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 ot= hers 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 f= reebsd 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 look= up > >>>> table. > >>>> > >>>> We also added the kern.supported_archs sysctl last year to all branc= hes > >>>> to enable figuring out which architectures a given running kernel > >>>> supports (e.g. amd64 and i386 on most amd64 systems). This was desig= ned > >>>> 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 sa= y that it > > is in 8.4) >=20 > It means we can do it now. Very few people install i386 packages on=20 > amd64 anyway. It means people with very old releases on old branches=20 > might face a warning in an unusual situation. Not a big deal. Since we=20 > only provide i386 and amd64 packages anyway, this is also a trivial=20 > special case if you really want that. >=20 > >>> And it defeats cross installation (which is the reason why the ABI su= pported 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 w= ill need > > to know what arch could be supported by the "content" of the chroot. >=20 > uname -p in the chroot (I guess this is with qemu) should return the=20 > right answer, just as it does with an i386 chroot. If it doesn't,=20 > 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 >=20 > >>> and last thing is the current build packages should just work meaning= that we > >>> would need to have a kind of mapping table > >> Sure, as a compat measure. No reason to lock it in forever. You could > >> also detect old-style strings with a warning and install them > >> unconditionally. It's not a big deal. > > sure but one has to write it :) > > >=20 > That's fine. I'm happy to. > -Nathan > _______________________________________________ > svn-src-all@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/svn-src-all > To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" --c8JyeaiReRNoiMDS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlN/oQUACgkQ8kTtMUmk6Ey5VACeKoOCqibxWc4XnEBpniIQ4zFe w74An3j+oPNGb2Q9vAP8pvovK7/Vr6YG =1bbm -----END PGP SIGNATURE----- --c8JyeaiReRNoiMDS--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140523192701.GL72340>