Olivier Crête <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 08 Dec 2008 19:43:42 -0500:
> I'm not suggesting waiting any longer, just not pushing ebuilds into the > tree until we have a stable enough version of portage that handles them > (and if we do, then lets mark it as stable..). FWIW this ~arch user's perspective: AFAIK, the policy is now that no EAPI is allowed to pass where the corresponding version of portage is, stability-wise. That means, if a portage supporting that EAPI is only available in overlays, ebuilds/ eclasses supporting it must also remain in overlays -- they can't be added to the tree. (It's worth mentioning here that overlays aren't restricted to portage features at all, some use features not in portage, period, only in one of the other PMs.) Once a portage supporting that EAPI is in the tree, hard-masked for testing, ebuilds using it may also be in the tree, but also hard-masked. Once a portage supporting that EAPI is in ~arch for testing, then ebuilds using it can likewise move to ~arch for testing, but they can't go stable yet. Only after a portage supporting a particular EAPI is stable can an ebuild requiring that EAPI stabilize as well. Note that in the above there's NOTHING stating that an ebuild that's in ~arch for testing, cannot switch to an EAPI only likewise in ~arch for testing. It's quite possible that such an ebuild still in ~arch will be found to work better with features only in a new EAPI, and it's quite legitimate in my opinion to change the ~arch ebuild (still testing, remember) to require it, as long as a version of portage with support is already in ~arch as well. Of course, by doing so the maintainer accepts that he may not stabilize that ebuild until the supporting portage goes stable as well, but if that's the case, there should be nothing blocking an existing ~arch ebuild from being modified to require an existing ~arch portage, both of them still being in ~arch testing, after all. If people want to play with a few ~arch packages here or there, while most of the system stays arch/stable, fine, but the choice and results of the choice should both be their responsibility. Maintaining devs shouldn't have to worry about changing an ebuild that after all is still in ~arch, if they judge it will ultimately make for a more stable ebuild headed into stable. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
