On Thursday, 12 January 2017 05:23:52 IST Kevin Kofler wrote:
> 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.

Correct.

> Those use cases are much better served by full GNU sysroots (/usr/target, not 
> /usr/lib/target).

Incorrect.
As I mentioned in another thread, sysroot force you to place your libraries
under the sysroot. IFF all you build are end applications, multiarch has no
advantage over sysroot, BUT...

If someone use sysroot and need to develop many libraries, they:
 * Either need to move the built libraries under the sysroot
   so the cross-compiler will link applications with them.
 * Or (as you suggested elsewhere), build them twice: first for
   the target device and than (with sysroot prefix) for the sysroot.

Both alternatives are far worse than the nice multiarch solution
which is building once and use the same binary package both on the
target device and for your cross-compiling.

To set the record straight:
 * Multiarch is paradigm shift and maybe Fedora use-cases doesn't
   warrant going this last-mile.
 * But claiming multilib is "better" than multiarch is simply wrong:
   multiarch solve the general case, while multilib solve only the
   specific case you described.
   (both archs are executable but one is prefered).

Bye,

-- 
Oron Peled                                 Voice: +972-4-8228492
o...@actcom.co.il                  http://users.actcom.co.il/~oron

The most exciting phrase to hear in science, the one that heralds new
 discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
                 -- Isaac Asimov
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to