svn commit: r266553 - head/release/scripts

[Baptiste Daroussin]

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
-------------- 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-all/attachments/20140523/7fbe7fa1/attachment.sig>