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 

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

Reply via email to