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

[Brian Harring]

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