On 05/23/14 10:24, Bryan Drewery wrote:
On 2014-05-23 12:11, 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.
Symlinks are irrelevant for pkg. It may fetch based on ABI in the URL,
but once it opens the package it also compares the ABI from the package
and repository to the ABI of /bin/sh on the system. So the symlink
wouldn't
help.
That is a highly questionable design choice. Why not just check
MACHINE_ARCH?
In any case, packages only exist for i386 and amd64 in the wild in a
supported way. Those two can be special cased for compatibility in about
two lines of code if you're worried about this.
-Nathan
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
