-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Harring wrote: > 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).
Since incompatible changes require an EAPI bump, backward compatibility is automatically handled by EAPI. >> 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. Incompatible changes for a given EAPI specification are simply unacceptable. People really should know better than that. If not, educate 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 We can design it to be overlay friendly. An overlay can be viewed as a child derivation of a parent repo. The child inherits from the parent and can override it. Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFAcwM/ejvha5XGaMRAntEAJ48SPKfOn6Ar+e57qyG+VTznVtppgCgpDiO Pra2VFJsst4N9dxXIBzWtzo= =MzKj -----END PGP SIGNATURE----- -- gentoo-portage-dev@gentoo.org mailing list
