Zac Medico wrote: >>>> 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. >
See this is a bad idea. If you give them a hand, they take the whole arm... You don't presently export a ton of stuff to developers for their tinkering (bashrc aside, that affects them locally only). The bad part being you get to maintain it; the good part being you also have full control of what goes on. Once that control is gone you can't really guarantee much...."Just educate them" means that 50% of developers will have NFC what EAPI means and the other 50% will break it because it helps make their job easier. Just as when you add functionality now with no EAPI bump; it often gets used immediately (although thank god most people are smart enough to add the correct DEPEND statements). You give up that control and you end up with another large area of the tree to QA and no real way to do so. -- gentoo-portage-dev@gentoo.org mailing list
