On Thu, Sep 07, 2006 at 10:22:38AM -0700, Zac Medico wrote: > Simon Stelling wrote: > > Zac Medico wrote: > >> Well, if the metadata generation step is viewed as being separate from the > >> rest, > >> and the helpers aren't needed during that step, then it's possible to get > >> the > >> EAPI from the ebuild without the helpers being in the environment. Once > >> the > >> EAPI is known, the package manager can use that to determine what else (if > >> anthing) needs to be added to the environment. Then you'd only need a way > >> to > >> tell the package manager which EAPI levels the functions in your > >> install-helpers.eclass (or whatever) apply to. > > > > That is a workaround, but it makes a pretty hard link between the > > package manager and the functions, which is exactly what I am trying to > > cut through with the patch. Sure, it'd be a workaround, but just keeping > > them in the portage package until EAPI=1 is reached is one too... > > It's not intended as a workaround and it shouldn't create a hard link between > the package manager and the functions. The idea is that the tree should > provide > the necessary information for the package manager (portage or not) to > determine > how it should setup the environment for a given EAPI. The file containing the > functions from install-helpers.eclass would have to be labeled in some way > such > that any package manager would know that those functions are required when > EAPI=0 (and possible other EAPI levels).
Just so we're clear... if gentoo-x86 wants to define their own base template all ebuilds in that repo use, that's fine. That's a different beast from moving the format definition into the tree though. Kind of curious if either of you have thought through the implications of moving this functionality into the tree for the vdb and binpkgs also (short version, even with ebds env handling its not going to be pretty for backwards compatibility). > >>>> So, the correct way to do it is to define an EAPI=1 that does no longer > >>>> include these helper functions and make the eclasses/ebuilds that use it > >>>> inherit the eclass manually. However, this will need to run through -dev > >>>> and I'm afraid the ebuild devs wouldn't like it at all :-/ > >> They won't like it because it's expected that EAPI will provide the > >> necessary > >> information. Why should they have to inherit some special eclass if it's > >> already implied by the EAPI that they've specified? > > > > It wouldn't be implied anymore. The install-helpers.eclass would > > actually be like every other eclass, like eutils fex. > > Fine, but the EAPI can still be used to imply that some other functions may or > may not be available. Not really. Via moving parts of the format into gentoo-x86 it's implciitly setting it up such that whatever tree portage is working against now defines EAPI. Sounds whacky, but think it through; instead of trying to verify that 3 package managers are EAPI compliant, it's now dependant on the environment the tree defines, as such the tree can redefine the env without bumping the EAPI. Yes that's stupid to do, but moving the format into the tree enables it. Theres a reason no other package format has their actual format definitions (env setup in our case) shoved into the repo, and thats one of them. > > Actually, the reason they won't like it for will more likely be that it > > requires adding another eclass to the inherit line for ~15'000 ebuilds. > > See, that statement shows me that you've missed my point that EAPI can be used > to imply which functions are implicitly available. It would be redundant to > inherit an eclass containing functions that are already implied by the EAPI. Would require 24,600 (last count) mods to ebuilds to specify an elib import moreso; automagically trying to import an elib out of a repository is pretty much guranteed to not behave as desired (overlays again come to mind). Eclasses are designed as crappy oop; what this change means for eclasses/elibs is that instead of reusing functionality, functionality gets copy/pasted across repositories- not a good thing. ~harring
pgpeOqGvPDsqS.pgp
Description: PGP signature
