Neal Gompa wrote:
> It's not true that we need to change anything (as Kevin Kofler
> suggested earlier in the thread) for this to be useful. There is no
> policy change required for this to be an improvement over the
> situation today.
This is wrong, because, as you wrote:
> Binaries are not duplicated with the "Debian multiarch".
So to support the one use case that multiarch supports and multilib does
not:
> enabling larger scale cross-compiling, and supporting loading binaries
> intended for different architectures or kernels
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. Those use cases are much better served by full GNU
sysroots (/usr/target, not /usr/lib/target).
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
