On Sun, 25 Aug 2013 16:15:31 +0200 Ulrich Mueller <[email protected]> wrote: > > first version (multilib1.patch) directly changes the output of the > > currently used multilib_is_native_abi() function: > > I think this would be very misleading. If a function is called > multilib_is_native_abi then it should test for exactly that, not for > something else.
Native abi only really makes sense as 'the abi you want the binaries for'; maybe it is misleading, but i don't think it's worth changing the name. However, these patches do not make sense as the only thing they do is allowing building binaries twice so that the 'native abi' ones override the previously built binaries. The justification for this is an invalid, utterly broken, hypothetical case where people install packages with invalid settings (disabling default/native abi). Even if we want to support this approach, this will not work that easily: Some packages install both binaries and libraries; usually the binaries have more deps than the libraries, hence the correct dep string for this packages is [MULTILIB_USEDEP] on the deps of the libraries and a plain dep (assuming native abi) for the rest. Look at e.g. jack-audio-connection-kit or lame. Anything else is bloated. If we want to allow multibin, or rather a mixed system where some bins have ABI A and some others have ABI B, this will require a more thorough solution than these quick hacks: With one of these patches, if you ask for building all the binaries and disable your native abi, you get a binary with a non native ABI but also get broken deps in your packages since they do not RDEPEND on the correct ABI of its deps. Alexis.
