On Sun, 17 May 2009 21:03:46 +0200 Tiziano Müller <dev-z...@gentoo.org> wrote:
> 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). I don't understand. Removing a runtime dependency of a package will break it regardless of whether or not it's referenced in the package's VDB. We don't prevent uninstalling dependencies, so how does having it referenced prevent breakage? The only case I can think of is depclean, but it already checks to see if removing a package will break the linkage map of another installed package. > 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? Since when do we track reverse deps for uninstalls? > > 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. Exactly. :) It's not the EAPI itself that requires the revbump, it's the changes the EAPI makes. That's all I'm saying. And in the case of going from EAPI 0 to EAPI 1, the changes are not those that require a revbump. If I were going from EAPI 1 to 2, and I'm using the default src_compile, then yes, a revbump is in order. > > 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? If the user is installing a package that doesn't have a stable version with an EAPI that their package manager supports, then it's no different than if they are installing a package that doesn't have a stable version with their KEYWORDS. And when unmasking ~arch packages, you often have to unmask ~arch dependencies. Portage is just another of these dependencies. -- 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
