Am Sonntag, den 17.05.2009, 11:11 -0600 schrieb Ryan Hill: > 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. Which is mostly wrong as well since a change in dependency means that the currently installed stuff may break if a package (the new dependency for example) gets removed and since the package you changed does not reference it, it gets broken (for example if you had a magic dep before and add it now as an explicit dep). So, unless you're doing a pkgmove it's a dangerous thing since the PM can't reliably track reverse deps when doing uninstalls since it has to use the vdb entry for that, doesn't it?
> So I'd argue that an > EAPI change does not require a revision bump in and of itself. EAPI may imply a decent implicit change to the ebuild and therefore needs a rev-bump as per the manual. > 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. And how much time a portage with a new EAPI got stabled? (see for example early python eapi bumps) > > 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? It would maybe suggest to update to an unstable version of portage, not so good then? -- Tiziano Müller Gentoo Linux Developer, Council Member Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
