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.
Yes, multiarch requires changing things.
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?
-- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
