From owner-svn-src-all@FreeBSD.ORG Sat May 24 02:33:09 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 AB813FC0 for ; Sat, 24 May 2014 02:33:09 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 8AEF52E22 for ; Sat, 24 May 2014 02:33:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4O2X9an043669 for ; Sat, 24 May 2014 02:33:09 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4O2X9hl043663 for svn-src-all@freebsd.org; Sat, 24 May 2014 02:33:09 GMT (envelope-from bdrewery) Received: (qmail 15404 invoked from network); 23 May 2014 21:33:07 -0500 Received: from unknown (HELO roundcube.xk42.net) (10.10.5.5) by sweb.xzibition.com with SMTP; 23 May 2014 21:33:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 23 May 2014 21:33:07 -0500 From: Bryan Drewery To: Nathan Whitehorn Subject: Re: svn commit: r266553 - head/release/scripts Organization: FreeBSD In-Reply-To: <537FD679.6020503@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> <20140523192701.GL72340@ivaldir.etoilebsd.net> <537FBB4E.2010409@freebsd.org> <8740c21d1e7467ea0e0355c5d05729c9@shatow.net> <537FD679.6020503@freebsd.org> Message-ID: <5b0a2eff4e47cf9dd7365f3884c4e026@shatow.net> X-Sender: bdrewery@FreeBSD.org User-Agent: Roundcube Webmail/0.9.5 Cc: svn-src-head@freebsd.org, Baptiste Daroussin , src-committers@freebsd.org, svn-src-all@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: Sat, 24 May 2014 02:33:09 -0000 On 2014-05-23 18:15, Nathan Whitehorn wrote: > On 05/23/14 14:34, Bryan Drewery wrote: >> On 2014-05-23 16:19, Nathan Whitehorn wrote: >>> On 05/23/14 12:27, Baptiste Daroussin wrote: >>>> On Fri, May 23, 2014 at 12:01:08PM -0700, Nathan Whitehorn wrote: >>>>> 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 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. >>>>>> So We can switch after 8.4 death which is a good news (except if >>>>>> you say that it >>>>>> is in 8.4) >>>>> It means we can do it now. Very few people install i386 packages on >>>>> amd64 anyway. It means people with very old releases on old >>>>> branches >>>>> might face a warning in an unusual situation. Not a big deal. Since >>>>> we >>>>> only provide i386 and amd64 packages anyway, this is also a trivial >>>>> special case if you really want that. >>>>> >>>>>>>> And it defeats cross installation (which is the reason why the >>>>>>>> ABI supported 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 will need >>>>>> to know what arch could be supported by the "content" of the >>>>>> chroot. >>>>> uname -p in the chroot (I guess this is with qemu) should return >>>>> the >>>>> right answer, just as it does with an i386 chroot. If it doesn't, >>>>> 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 >>>> >>> >>> Knowing a priori which architectures are "supported" by a chroot >>> based >>> on ELF type of /bin/sh doesn't even work. How do you know what kernel >>> will be running in there and how it will be configured? You don't. >>> IA64 can -- sometimes -- run i386 binaries, for example. amd64 may or >>> may not be able to run i386, depending on kernel options. >>> >> >> You're assuming that you would only use a chroot to RUN things. This >> is >> also useful for building images. Install a world into a chroot, run >> pkg -c install whatever and it picks the right ABI. Just an example. > > No, I'm not. Suppose you make an amd64 jail and install an i386 > package into it. That's fine (or is potentially fine anyway). But > there is no way to be sure since whether it's fine or not depends on > the kernel you happen to run. > >>> In any case, I wouldn't really characterize this situation as >>> "common" >>> in any sense -- and I don't even see why it applies to this >>> discussion. Whatever logic calculates your own private version of >>> architecture strings can calculate the correct ones. Allowing it to >>> ignore the architecture optionally, just like you how you already >>> have >>> to add flags to install in a chroot, would also work. Lots of things >>> like that. This issue is basically wholly unrelated to whether you >>> use >>> normal architecture strings or not. >>> >>> I'm perfectly happy to write 100% of the code to enable pkg to use >>> the >>> same architecture strings that the rest of the operating system uses. >>> Having private ones is just a recipe for confusion. From this >>> discussion, there don't seem to be any actually existing reasons why >>> MACHINE_ARCH doesn't work for this. >> >> pkg is *not* FreeBSD-specific. Is MACHINE_ARCH portable? > > Yes, of course. I think it's part of POSIX. The GNU and OS X versions > of uname have it anyway. > > I'm really quite mystified why you're so insistent on having your own > private ABI identifier strings. If you're really set on this, I of > course can't make you change. As you note, pkg is not something that > lives in FreeBSD and I have no power to change it. And, from this > conversation, I now strongly suspect that if I did put in the work to > fix this, my patch would be ignored or rejected. But it does mystify > me. > -Nathan Well "highly questioning the design choice" is quite a rude attitude. It's not a good way to collaborate. -- Regards, Bryan Drewery