On 01/12/2017 06:49 AM, Neal Gompa wrote:
On Thu, Jan 12, 2017 at 9:26 AM, Brendan Conoboy <blc@xxxxxxxxxx> wrote:
On 01/11/2017 08:23 PM, Kevin Kofler wrote:
you must absolutely split the binaries (which would conflict with the
native
binaries) and the libraries (which you need to do your cross-compilation
or
to run your non-native binaries) into separate subpackages wherever
packages
currently ship both, or modify RPM's ELF coloring heuristics to be a lot
more complex and also to take the system's actual native architecture into
account.
FHS multilib is designed only for binaries that can be natively executed,
where there is a clear, fixed preference on one architecture over another.
(If you can run both i686 and x86_64 binaries, you automatically want the
x86_64 one in case of conflicts.) Debian multiarch attempts to support use
cases that fail that assumption hardcoded deep into RPM and into Fedora
packaging practices.
While it is true that RPM does assume native across the board at the
build stage, it does have some support for not assuming that at
install time. There is a tiny bit of scaffolding for supporting a
cross-compile/multi-arch build case in RPM, though it definitely would
need work. Some time ago, I had filed a bug upstream about this[1],
but depending on where we want to go with this, it might become even
more important.
But most of the problems are not at the RPM level, they are at
Fedora's packaging level. That being said, just changing from
/lib<qual> to /lib/<triple> is somewhat of an improvement in its own
right, as people who are building but not necessarily packaging can
leverage libraries to run arbitrary foreign architectures.
[1]: https://github.com/rpm-software-management/rpm/issues/103
Yes, multiarch requires changing things.
Using platform libdirs is admittedly a half-step (as Kevin points out,
fully implementing Debian-style multiarch requires a lot more
splitting than what Fedora is used to, though I think this is
basically second nature for the majority of RPM-based distributions).
Those use cases are much better served by full GNU
sysroots (/usr/target, not /usr/lib/target).
Hey, I can agree to that. Can you agree that /usr/bin could then be a
symlink or linkfarm to /usr/target/usr/bin?
So you're instead proposing that we move fully to sysroot style for
everything? Not that it's necessarily a bad thing, but we'll have to
bend quite a lot of things to make that work, especially since
sysroots are designed to host their own full FHS (including /etc,
/var, and /share). The tricky part the comes with how do we handle
maintaining a shared configuration state with multiarch configurations
(i686 on x86_64, armv7hl on aarch64, riscv on riscv, etc.). Currently,
we can make the assumption that directories like /etc, /var,
/usr/share, etc. contain common data. But sysroots, by definition,
cannot make that assumption.
Not everything, just the architecture specific bits.
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
