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. What do we do then? -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
