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) > > > 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. > > > 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 :) > -nathan > regards, Bapt
pgpRw5OLQiGd9.pgp
Description: PGP signature
