On 03/02/2013 12:08 PM, Alexis Ballier wrote:
>
>> eclass level:
>> pro:
>> - easier to maintain (eclasses are generally easy understandable)
>> - quicker to fix and to extend
>> - solution is NOW available
>> con:
>> - more likely to break stuff as all eclass based solutions, because
>> there are no eclass-APIs and no spec
>
> if done correctly this should not happen, but that's true the eapi
> barrier is not there.
>
>> - needs much more modification on ebuilds, especially for weird
>> build systems
>
> the eclass you proposed implements more or less the multilib-portage
> solution without much changes. if you want to do it cleanly (out of
> source build, etc) then yes you need much more changes but also get
> something you cannot do from the PM side.
>
>> - not tree-wide, slow per-package migration
>
> it is a pro rather than a con for me: do we really want lib32 to be the
> 32bits copy of lib64? or do we want here only what actually makes
> sense, on a per-package and per-need basis? (see also the tl-latexextra
> example above)
>
IMO we should go on with eclass development. Tommy has already offered
to help with that, but would appreciate if we implement a check/switch
that will disable all multilib-eclass related magic and allowing
multilib-portage to still work tree-wide as it did before we invented
these eclasses.
I think that's a fair trade.
And at least for my eclass I already have implemented a solution,
basically doing:
if [[ $(multilib_get_enabled_abis) == ${DEFAULT_ABI} ]] ; then
DISABLE_MULTILIB="ON"
fi
which will disable multilib-behavior if only the default abi is set.
Alternatively we could simply introduce DISABLE_MULTILIB as an eclass
variable which can be set by multilib-portage then.
Mgorny still has not replied to this proposition.
