[gentoo-dev] Re: EAPI Changes

[Ryan Hill]

On Sun, 17 May 2009 21:03:46 +0200
Tiziano Müller <dev-zero@g.o> 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-zero@g.o> 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