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
