Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

[Alexis Ballier]

On Mon, 19 Oct 2015 13:17:13 -0400
Rich Freeman <rich0@g.o> wrote:

> On Mon, Oct 19, 2015 at 10:21 AM, Alexis Ballier
> <aballier@g.o> wrote:
> > On Mon, 19 Oct 2015 09:51:20 -0400
> > Rich Freeman <rich0@g.o> wrote:
> > [...]
> >> >
> >> >> I'd say the best approach for compatibility if you have an
> >> >> existing eclass and it already exports src_prepare is to not
> >> >> call eapply_user unless it firmly falls into the #2 category
> >> >> above.
> >> >
> >> > Replace 'not call eapply_user' by 'not export src_prepare' and
> >> > I'd agree with you if going a bit further by ensuring there is
> >> > no hidden problem:
> >>
> >> Well, taken together my recommendation does amount to:
> >> 1.  Avoid exporting src_prepare at all.
> >> 2.  If you do export src_prepare, then don't call eapply_user.
> >
> > 2. sucks: an ebuild inheriting that eclass will have to redefine
> > src_prepare in order not to break with eapi6, so  there's no point
> > in exporting the function in the first place.
>
> No argument.  I'm just saying that nothing stops us from using an
> existing eclass with EAPI6 without changing function names all over
> the tree.  Non-EAPI6 ebuilds can still use the existing function
> automatically, and new ebuilds using EAPI6 have to work around the
> issue until the eclass is revisioned.

ok, or the eclass can change api with eapi6 which is quite common, and
preferably *before* any eapi6 ebuild uses it
again, history doesn't have to repeat itself, but it has shown that if
eclasses aren't updated properly quickly, it'd be a mess

> >
> > Also, since you seem to know well KDE: where would you call
> > eapply_user, in kde eclasses or cmake-utils ?
> >
>
> Definitely in a kde eclass.  cmake-utils would fall into the category
> of a utility eclass, so it ideally shouldn't export phase functions at
> all.  Again, I'm not proposing forcing a change on that now, and it
> needs more thought, but it would be a lousy place to put eapply_user
> since it could be used in the same ebuild as another eclass that
> performs a similar function.
>
> That might require having the kde eclass call the cmake-utils eclass
> function.  Since the kde eclass is only intended to be used by kde
> ebuilds maintained by the same group that maintains the eclass, there
> isn't a problem here.  The ebuilds themselves just set a bunch of
> variables and leave the work to the eclass.

That's what I feared... I would definitely put it in cmake-utils, since
the idea behind all those *-utils.eclass is that they're fed with
options and do all the grunt work for you. Think of them as default
phases for a given build system. What you propose is close to having
eapply_user mandatory in eapi6 but having default src_prepare not
calling it...
Following your criteria, the list I provided is very far from complete,
and should include all the *-utils eclass, multilib ones, and
probably many others I don't even dare to look for.

However, as you say, putting it in cmake-utils needs to be properly
thought so that it doesn't conflict with other eclasses: Hence the need
to properly define what eclasses should call eapply_user and apply
patches and what should not.

Your initial argument was very convincing, but under those conditions,
it seems way much saner to make eapply_user idempotent and be done.
(and maybe in addition require informally that eapply_user is called
after applying patches, but that'd fall under good practices rather
than rules)