Re: [gentoo-mips] multilib problems on mips64 profiles

["Anthony G. Basile" <basile@opensource.dyc.edu>]

On 09/21/14 21:29, Joshua Kinard wrote:
> On 09/21/2014 21:12, Anthony G. Basile wrote:
>> On 09/21/14 21:11, Anthony G. Basile wrote:
>>>> Correct me if wrong, but it seems the core problem here is that multilib
>>>> inherits from the o32 base profile.  While I think the proper longterm
>>>> fix is
>>>> to have more discrete, modular/pluggable profile components (like OOP and
>>>> multiple base classes), that's not going to happen in Portage for a
>>>> long time.
>>>
>>> Not exactly.  The problem is that everything inherits from
>>> profiles/arch/mips and currently that forces o32 with mgorny's multilib
>>> stuff.  We need to get that out of the way for the other profiles that
>>> inherit it.
>>
>> Oh wait, maybe we mean the same thing here.  I'm not sure.  When you say the
>> same base profile, do you mean profile/arch/mips?  In that case we are saying
>> the same thing.
>
> I actually forgot about arch/mips in the profiles.  I'll have to dig around in
> there later on.  I assumed we (the MIPS team) managed everything MIPS in the
> tree, since -embedded used to compartmentalize everything under their embedded
> profiles.
>
> The modular profiles bit is a longterm item.  I don't know if this mixins thing
> will correct our issues or not.  If not, I may just have to dive into Portage
> and write my own profile-parsing code and try my modular idea out to see if
> that really does solve nay problems.
>

The mixins can help this issue but will not correct it.  The problem is 
the current inheritance model is so uncontrollable.  Everything I do is 
always so-so.  I can never get it right.  I would love it if we just did 
away with parent files and stacked manually in the last profile that we 
export to the user.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197