On Fri, 15 May 2009 23:31:25 +0200 Tiziano Müller <dev-z...@gentoo.org> wrote:
> Wrong. For example: > - stuff like docompress may change the content being installed depending > on the package manager > - --disable-static (maybe in a later EAPI) changes content > - slot-dep-operators change the rdepend of installed packages, so it > changes how the package manager has to handle reverse packages on > uninstall (in EAPI 3) None of which are a problem when changing the EAPI from 0 to 1, which is the situation here. The first two examples fall under the currently established guideline of revbumping when content changes (and I emphasize guideline). I don't see how the third example is any different than adding or removing dependencies, which also does not require a revbump. So I'd argue that an EAPI change does not require a revision bump in and of itself. That's not to say it shouldn't be done if the situation allows, or you have any doubts, or just because you want to. But unconditionally putting an ebuild through full ~arch to stable cycle because you added a simple SLOT dependency or a + to a USE flag is bureaucratic nonsense. > And we also always said that a rev bump should be done on non trivial > changes or non-build-fixes and changing the EAPI is technical seen > mostly a non-trivial change. As above, it depends on the situation. 0 -> 1 is a trivial change. > Do we want to document the following? (do we have already?) > - When is it allowed to use an EAPI in the tree (given as offset to the > release of portage supporting that eapi) > - When is it allowed to use an EAPI in the stable tree (given as offset > of when a portage version supporting that EAPI got stable) As soon as a version of portage supporting that EAPI is available. This is the entire point of the EAPI, that we don't have to wait X amount of time before using new features. If the user hasn't updated portage yet, they simply won't see ebuilds which use the new EAPI. We may want to document a suggested waiting time before removing ebuilds using older EAPI's. For example, should we always keep an EAPI 0 ebuild in stable as a fallback? Or if the user tries to install or update a package where all versions are masked by EAPI, should (does?) portage suggest updating itself? How long should we keep core system packages at earlier EAPI's? -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
