svn commit: r266553 - head/release/scripts

[Baptiste Daroussin]

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
> 
> > - 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?
> 
> 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 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

And it defeats cross installation (which is the reason why the ABI supported is
read from a binary and not from kernel)

and last thing is the current build packages should just work meaning that we
would need to have a kind of mapping table
-------------- 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/eaa620a3/attachment.sig>