Re: [gentoo-dev] Moving functionality out of portage and into the tree

[Ned Ludd]

I fully support this as long as I'm in said group that can commit on
these things or get a speedy response from somebody else that is. 
If initially if it's going to be limited I'd suggest the base-system,
portage and toolchain herds.

I'm also in favor of moving not just the do* stuff but also much of the
prep* that can be safely moved out of
/home/cvsroot/gentoo-src/portage/bin/ as well.

Thank you ferringb for mustering up this email to shed light on the
situation.

On Thu, 2004-07-29 at 05:36, Brian Harring wrote:
> 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
-- 
Ned Ludd <solar@g.o>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer