-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alec Warner wrote: > Zac Medico wrote: >> 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.
But you don't have absolute control. This is free software, and people can always fork or create an entirely new package manager (paludis and pkgcore, anyone?) that has EAPI differences (subtle or not so subtle). By moving the EAPI support into the tree, it allows different package managers to share the same EAPI support code. > 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. I'm not convinced that this type of restriction of freedoms is the best way to go about preventing EAPI breakage. Perhaps there should be a special herd that maintains the EAPI specific portions of the tree. A similar type of API breakage can already occur via eclasses, so I'm not seeing a big difference here. Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFAfxy/ejvha5XGaMRAuWpAJ9Niew8KSeBqsjIKkOBNHRxlQIfYgCguELD XscxgIQ0I8mq8rYfF3GMikY= =DL/m -----END PGP SIGNATURE----- -- gentoo-portage-dev@gentoo.org mailing list
