Re: [gentoo-portage-dev] Moving ebuild-related where they belong

[Brian Harring]

On Thu, Sep 07, 2006 at 07:11:01PM +0200, Simon Stelling wrote:
> Brian Harring wrote:
> > Make this change, and it means that all overlays that can function as
> > standalone, must bundle the eapi helpers themselves.
>
> Standalone-repos will have that
> problem, but there is none yet to my knowledge. Sure, the problem
> persists for future repos, but it's not so much of a deal to copy an
> eclass once.

Err... that's rather whacky.

You're suggesting that a fix in an eapi class must be copied into 
*every* standalone repo; lets pretend for a moment that glep19 
actually got somewhere, and subtree generation is possible.

We'll pretend that a 1k admins use it to filter down to 
lamp/mailserver/whatever, point is, they generated their own stand 
alone.

See where the "we'll just copy it around" starts to break down and go 
mildly apeshit?

> Also, as it stands today, portage IS connected to gentoo-x86 through
> exactly these helpers.

Not really.

Yes, portage knows the names of a few pkgs, but those pkgs are defined 
in the tree; in that respect, it's actually semi-sanely designed.

Point there is that portage can be ran against a foreign tree without 
needing gentoo-x86; frankly, claiming otherwise is a bit daft and 
requires real world examples of where it breaks down.


> Upon the needs of the portage tree the functions
> in portage are changed, and this is simply not correct.

This assertion doesn't make any sense; clarify please.


> > This is ignoring the potential fun of an overlay that redefines an
> > eapi locked function.
>
> eclasses in overlays that also exist in the tree are fun anyway. If
> people are messing with eutils, we tell them that it is entirely their
> responsibility if something breaks. Same goes for install-helpers.eclass.
> That being said, this problem already exists today: A custom eclass
> could simply define a function 'dosbin' and ebuild.sh would use that
> one. While it's a possible cause for breakage, it's not an argument
> against the move.

There's a real difference however for the dosbin example; the eclass 
can wrap the functionality, not flat out replacing it.  If it's a 
func, you're boned trying to get at the original, non-wrapped dosbin.

Move it into the tree, and you enable people to accidentally cause 
mayhem on a repository wide scale via tinkering with bundled bits of 
the eapi format; folks can do it now, but this makes it *far* easier.

> > A) requirement of trying to keep helper functionality exactly in sync
> > per tree,
>
> If the helpers were a part of the EAPI those trees would have to verify
> that the EAPI portage provides matches their needs.

The assertion there was that you would be stuck copying eclasses 
across all repos that exist; thus not addressing that assertion 
(should have been clearer, pardon).

Thing I think you're missing here is that the ebuild format is not 
bound to gentoo-x86, nor is portage; thus trying to move intrinsic 
bits of the format into gentoo-x86 goes pretty hardcore against the 
goal of ever trying to sanely support N standalone repos due to the 
fact each repo now can now carry it's own potential offshoot of the 
eapi spec.
~harring