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
pgpUQjEKtSjJO.pgp
Description: PGP signature
