Just an FYI, games-emulation/dosbox tripped over this recently.

On Sat, Aug 6, 2016 at 7:05 AM, Andrew Savchenko <bircoph@gentoo.org> wrote:

> Hi,
>
> On Sat, 30 Jul 2016 12:34:07 +0300 Andrew Savchenko wrote:
> > On Sat, 30 Jul 2016 07:37:08 +0200 Michał Górny wrote:
> > > > @@ -116,7 +123,8 @@ ESVN_PROJECT="${ESVN_PROJECT:-${PN/-svn}}"
> > > >
> > > >  # @ECLASS-VARIABLE: ESVN_BOOTSTRAP
> > > >  # @DESCRIPTION:
> > > > -# bootstrap script or command like autogen.sh or etc..
> > > > +# Bootstrap script or command like autogen.sh or etc..
> > > > +# Removed in EAPI 6 and later.
> > > >  ESVN_BOOTSTRAP="${ESVN_BOOTSTRAP:-}"
> > > >
> > > >  # @ECLASS-VARIABLE: ESVN_PATCHES
> > > > @@ -127,6 +135,8 @@ ESVN_BOOTSTRAP="${ESVN_BOOTSTRAP:-}"
> > > >  #
> > > >  # Patches are searched both in ${PWD} and ${FILESDIR}, if not found
> in either
> > > >  # location, the installation dies.
> > > > +#
> > > > +# Removed in EAPI 6 and later, use PATCHES instead.
> > > >  ESVN_PATCHES="${ESVN_PATCHES:-}"
> > >
> > > It would be a good idea to check if the variables are set and die if
> > > they are, so people don't accidentally use them.
> >
> > Impossible to implement. These variables (as well as all other
> > ESVN_* variables) are usually set after subversion eclass is
> > inherited. And even if I'll duplicate this check in all available
> > functions (which is ridiculous by itself), it still will not help,
> > since several functions are removed from EAPI 6 and people may
> > rely on default behaviour of src_prepare() alone.
> >
> > > >  # @ECLASS-VARIABLE: ESVN_RESTRICT
> > > > @@ -355,7 +365,10 @@ subversion_fetch() {
> > > >  # @FUNCTION: subversion_bootstrap
> > > >  # @DESCRIPTION:
> > > >  # Apply patches in ${ESVN_PATCHES} and run ${ESVN_BOOTSTRAP} if
> specified.
> > > > +# Removed in EAPI 6 and later.
> > > >  subversion_bootstrap() {
> > > > + has "${EAPI:-0}" 6 && die "${FUNCNAME[1]} is removed from
> subversion.eclass in EAPI 6 and later"
> > > > +
> > >
> > > Reverse the logic. This will require updating in every EAPI while it is
> > > rather unlikely the next EAPIs will return to previous behavior.
> >
> > Done.
>
> No further comments for a week => in the tree now.
> Thank you for review.
>
> Best regards,
> Andrew Savchenko
>