Gentoo Archives: gentoo-ppc-dev

From: David Chamberlain <daybird@g.o>
To: gentoo-core@g.o
Cc: gentooppc-dev@g.o
Subject: [gentooppc-dev] Re: [gentoo-core] ARCH=ppc in unified portage and some downfalls
Date: Mon, 10 Jun 2002 17:25:04
In Reply to: [gentooppc-dev] ARCH=ppc in unified portage and some downfalls by Mark Guertin
Hi Mark,

I'm in full agreement with you that work is needed on ports stability. 
 I think, however, that I have a slightly different perspective.  First, 
I think that it is amazing and groundbreaking that gentoo can have two 
different architectures running, if not perfectly, then at least very 
well indeed from a single package tree.  As you know, the ppc port is 
still really in its infancy, and it's a testament to the power of 
Portage that it works as well as it does already.  I think we need to 
decide what our priority is: is it to have a stable ppc distro asap, or 
is it to do something new and exciting, and still get a stable distro 
after just a little while longer - one that will be a model for linux 
distributions for some time to come?  To put it another way, to opt for 
separate trees would be to sacrifice exactly what is so special about 
gentoo-ppc: it's not a separate distro from gentoo-x86, it just _is_ 
Gentoo, and for me that's about as cool as it gets.

Another point: I've been using gentoo-x86 for quite a while now, and it 
has its own share of QA problems (and this is its acknowledged #1 
priority now).  For now, it's just the gentoo way to have a few things 
broken.  I'm not saying it should stay that way, but if gentoo-ppc 
"looks bad" because of broken stuff, that's not unique to gentoo-ppc :-)

Well, none of this invalidates your complaints - I just want to draw 
attention to the importance of priorities.  As for actual fixes, I'm all 
for the improved masking schemes.  I suggest, too, that we (ppc-devs) 
make it our business to stay up to date on exactly what gets changed in 
portage from this point of view, and to disseminate clear info to all 
other gentoo devs so they know what needs to be done.  Some important 
recent changes (slots, licenses...) have appeared without much 
documentation about usage, and that makes devs wary of using them.  We 
don't want this to be the case with changes that affect the ports.

Another idea (you and I discussed this one on irc the other day): since 
repoman and lintool are being made pretty much necessary for committing 
ebuilds, how about adding functionality to them to flag arch-dependent 
issues (e.g. if a patch is added to source, have lintool ask "is your 
patch arch-independent?").