Note: pardon the dual post, resending this since I managed to leave a
subject off of... any discussion regarding this, please start the thread
from this message... sorry about that :-)

Currently portage bundles all do* and new* scripts that ebuilds use with
each release.  In other words, the current breakage w/ dohtml -R not
handling files w/ spaces correctly is tied to a portage version
(<=.51_pre13).  Prior releases of portage will remain broke,
since the fix is tied to a portage release.

To head off the 'they should upgrade', yes, having a current portage is
important- that doesn't mean we can't split these files out so that they
*aren't* tied to a release.

Gentoo's pkg system is basically composed of two things; portage, the
executor of ebuild instructions, and the tree, the data for
compilation/installation of src.  Currently portage is basically
providing a collection of scripts/functions that are strictly used by
the ebuilds, basically a library of functions/scripts- basically 'data'
in the exec portion.

This 'library' should be placed into the tree, since portage isn't aware
of the scripts/functions even existing for the most part.  The do* and
new* scripts are specific to the customs we have for our tree, not
portage.

The scripts are kind of a no brainer for moving- what I'm also
proposing, is the creation of an ebuild-base eclass that is
automatically inherited, and lives in the tree.

Same thing, moving functions out of portage that are specific to our
tree, into the tree.

Fex: the amd64 crew is after being able to overload econf so that they
can specify where the 64bit libs should live; as it stands, they're
stuck until it's in a portage release.  If econf lived in the
ebuild-base class, this change could be flipped on regardless of the
users portage version.

The embedded crew are after something similar- see bug #55476, basically
need an addition to econf to do tweaks to configure scripts; as it
stands, they must wait for it a release.

The point of all of this is that these functions/scripts *aren't*
specific to portage the package, they're specific to our tree,
specifically the tree *at that moment*  I'd assume when it was decided
we would have these functions available for our ebuilds, they wound up
in the portage src for lack of a better place, which I view as the wrong
location.

Ebuild-base.eclass would hold econf, emake, ins*, and a few other
functions.

Assuming people have read this far, and agree, and this is actually
undertaken, the scripts/ebuild-base class should be controlled by a
herd- those who know the tree in and out would be best for the herd.
Basically, grab those who already are already doing serious QA of the
ebuilds in the tree.

As for actually doing these moves, it's pretty straightforward. 
Transferring the scripts out of portage pretty much consists of a PATH
addition in a portage release, for auto-inheriting ebuild-base.eclass,
addition of another src statement.  About it.

So... thoughts?
~brian