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

[Cory Visi]

Theory aside, it really sounds like your two examples and everyone else's 
follow-ups have do to with the QA time on portage releases. The real 
problem is not that these utilities are part of portage releases, but that 
portage releases take too long to come out.

Is moving them into the portage tree so every developer can have at it the 
right solution? Will QA on these "base" utilities be neglected? How can we 
assure the same type of care with these utilities is taken as with portage 
releases?

I'm not against this move, I just want to discuss these issues.

Thanks,
Cory

On Thu, Jul 29, 2004 at 04:36:35AM -0500, 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.

--
gentoo-dev@g.o mailing list