svn commit: r266553 - head/release/scripts

Fri May 23 19:27:07 UTC 2014

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
> 
> >>> 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 :)
> >
> 
> That's fine. I'm happy to.
> -Nathan
> _______________________________________________
> svn-src-all at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscribe at freebsd.org"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20140523/05326763/attachment.sig>