Hello All

I wanted to draft up some thoughts to get some opinions here...I've been 
fighting with many things PPC in the portage tree in the past little while 
and have stumbled accross some very difficult resolutions to things.  For the 
most part {$ARCH} = "ppc" is a working solution, but I have found a few 
places where it causes major heartaches (the recent xforms-089-r1 build which 
is now masked again is prime example of this).

I spent several days on this (very very simple) ebuild and had consultation 
with many devs in #gentoo-dev, and it appears that the 'working 3 days ago' 
version is no longer working, and I have no idea why at this point, but this 
is aside from the point of this email, I will track down the problems and 
address seperately, it requires big explanations...let me continue, this 
email is not about a single difficult ebuild.

One of the biggest problems with things for the ppc folks right now is the 
fact that so many things get comitted with no testing on the ppc platform (no 
one's fault, there are very few of us ppc devs at this point in time to test 
and holding back portage is not a good thing ;).  There is no Quality 
Assurance happening and it makes gentoo as a whole look very bad having end 
users test bugs in this manner IMHO.  I get a bevy of bugs reported every day 
(mostly in person in IRC, some on bugs) and the whole of portage has still 
yet to be tested on ppc.  The only way we are finding these errors are end 
users finding things that don't work when they try and install and either 
give up on the pkgs and/or gentoo, or reporting the bug and waiting for the 
fix to happen (where possible).

PPC/linux is definately not as mature as x86 linux, and many projects either 
just do not work on ppc and/or need major adjustments to work on ppc, and 
this is going to cause many many problems as things move along. In the PPC 
world it is pretty much standard that many 1.0 (0.1) versions of projects 
that are not explicity made for ppc work without hitches.  This issue is 
going to amplify drastically if/when sparc joins portage as well.  Another 
problem is that very few Gentoo builds are as simple as ./configure ; make ; 
make install and require many tweaks, and this along with various patches and 
updates applied to many ebuilds amplify things even more.  Many patches are 
to fix arch specific issues and do not apply globally.  This also holds true 
for ./configure options, USE options, tweaked Makefiles, etc.

Here are the some options I can see for a change at this point in the game: 

1) ppc go back to it's own rsync module/portage tree (at least for now until a 
better solution is at hand).. this would give us QA .. something not possible 
currently w/ ppc in a unified portage and I don't want gentoo ppc to get a 
'bad name' for everythign being broken

and/or

2) some sort of arch specific sectioning be built into portage somehow instead 
of having to use ARCH in multiple places within the same build (which could 
still lead to big messes as one ARCH may want to move forward a version while 
another ARCH must wait for a next vendor release for compatability, etc)

and/or 

3) a more intelligent masking setup that keeps a manageable by arch masking (I 
know this is currently possible, but would require much diligence on the part 
of _all_ devs comitting to cvs), some way of maybe auto-masking a new build 
until its 'released' from the ppc packages file by a ppc dev after its been 
tested.  This option would also allow users who wan't to test unkowns the 
option easily.

I'm not saying that things won't work within the current design... it's just 
exceedingly difficult to do some of the simplest of things (see xforms build) 
and I have fears (read nightmares) that this ARCH stuff may have a snowball 
effect as Gentoo grows.  IMHO quality control and adequate testing before 
release should be a very important part of any distribution, especailly one 
as good as Gentoo and the simple solution of  "we need more ppc devs" and/or 
"everything had to be tested on both ARCH's" is not going to be the soltuion 
required in this case :) 

Any thoughts?  (**Gerk ducks and runs**)

Gerk