From owner-svn-src-all@FreeBSD.ORG Sat May 24 02:38:59 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 204611B2; Sat, 24 May 2014 02:38:59 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 805332E40; Sat, 24 May 2014 02:38:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 1FDDD38064; Fri, 23 May 2014 21:38:57 -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 O0TjwF3H8VwJ; Fri, 23 May 2014 21:38:57 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id 5856C38063; Fri, 23 May 2014 21:38:55 -0500 (CDT) Message-ID: <5380063D.7090601@freebsd.org> Date: Fri, 23 May 2014 19:38:53 -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> <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> <5b0a2eff4e47cf9dd7365f3884c4e026@shatow.net> In-Reply-To: <5b0a2eff4e47cf9dd7365f3884c4e026@shatow.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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:38:59 -0000 On 05/23/14 19:33, Bryan Drewery wrote: > 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. > Apologies. I do wish you would consider the points made regardless of rudeness, however. -Nathan