Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux