On 2014-05-23 17:34, Bryan Drewery wrote:
On 2014-05-23 16:19, Nathan Whitehorn wrote:
On 05/23/14 12:27, Baptiste Daroussin wrote:
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
Knowing a priori which architectures are "supported" by a chroot based
on ELF type of /bin/sh doesn't even work. How do you know what kernel
will be running in there and how it will be configured? You don't.
IA64 can -- sometimes -- run i386 binaries, for example. amd64 may or
may not be able to run i386, depending on kernel options.
You're assuming that you would only use a chroot to RUN things. This is
also useful for building images. Install a world into a chroot, run
pkg -c install whatever and it picks the right ABI. Just an example.
In any case, I wouldn't really characterize this situation as "common"
in any sense -- and I don't even see why it applies to this
discussion. Whatever logic calculates your own private version of
architecture strings can calculate the correct ones. Allowing it to
ignore the architecture optionally, just like you how you already have
to add flags to install in a chroot, would also work. Lots of things
like that. This issue is basically wholly unrelated to whether you use
normal architecture strings or not.
I'm perfectly happy to write 100% of the code to enable pkg to use the
same architecture strings that the rest of the operating system uses.
Having private ones is just a recipe for confusion. From this
discussion, there don't seem to be any actually existing reasons why
MACHINE_ARCH doesn't work for this.
pkg is *not* FreeBSD-specific. Is MACHINE_ARCH portable?
I don't think it matters whether MACHINE_ARCH is portable. FreeBSD amd64
binaries are not going to run on Linux x86_64, for example. Setting pkg
ABI to something like freebsd:arm:armv6hf or freebsd:amd64:amd64 is
specific enough, and could allow installation if the last triplet is in
kern.supported_archs. Then you can have linux:fruit:banana packages that
will correctly not install on freebsd:amd64:amd64. The current mapping
is not intuitive.
- Nikolai Lifanov
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
