Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference

[Joshua Kinard <kumba@gentoo.org>]

On 06/16/2014 16:24, hasufell wrote:
> Joshua Kinard:
>> On 06/16/2014 15:47, hasufell wrote:
>>> Jeroen Roovers:
>>>> On Mon, 16 Jun 2014 19:31:58 +0000
>>>> hasufell <hasufell@gentoo.org> wrote:
>>>>
>>>>> Also check the history of this thread for a few proposed solutions.
>>>>
>>>> The history of this thread and the history of gx86-multilib and
>>>> crossdev development suggest that crossdev was doing nothing wrong until
>>>> gx86-multilib came around and a problem was found between them. Masking
>>>> either for the benefit of the other would be, and let me quote the
>>>> history of this thread out of context just to fit in with the tone and
>>>> mode this sub-thread has taken, "asinine".
>>>>
>>>
>>> This isn't about right or wrong. This is about actual breakage on stable
>>> systems.
>>>
>>> Solutions were proposed, nothing has happened for months.
>>>
>>> So I don't see what else we can do here other than taking more radical
>>> steps to INFORM users of these possible breakages... and that's exactly
>>> what a hardmask is for.
>>
>> What about those of us who have been using crossdev to generate
>> cross-compilers for years w/o issue, because we run non-multilib?
>> Hardmasking crossdev to solve multilib problems doesn't accomplish anything,
>> other than just irk us.  Why not hardmask the multilib stuff instead and
>> leave crossdev alone?
>>
> 
> Hardmask half of the tree instead of a single package? Does not sound
> reasonable. The fallout will be _huge_ for users who already run
> multilib. You will basically get an emerge dump of 500+ blockers.
> 

Which is why I followed with the next paragraph that neither hardmask
solution is really viable.  You inconvenience a group of people one way or
the other, even if you're only doing it just to raise a point and/or awareness.

>>
>> If so, is it sensible to allow crossdev to install a cross-toolchain when
>> the underlying machine architecture is the same, just a different ABI?
>> I.e., would a solution be to prevent i686-on-x86_64 or mips64-on-mips, but
>> still allow mips64-on-x86_64, and such?
>>
> 
> That was already discussed and it will break:
>> yes, serving as a distcc server for x86 hosts or using 'cross emerge'
>> to build a x86 root from scratch

Then, can crossdev be augmented to work around the invalid behavior?  Has
anyone looked at crossdev's source to see if the issue can be corrected with
a patch?  Can the offending feature be made optional via a USE flag?  There
are other options available than simply hardmasking a package that many find
useful.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic