On Mon, 7 May 2012 17:17:10 +0200
Ulrich Mueller <email@example.com> wrote:
> >>>>> On Mon, 7 May 2012, Ciaran McCreesh wrote:
> > On Mon, 7 May 2012 02:12:14 +0200
> > Ulrich Mueller <firstname.lastname@example.org> wrote:
> >> | Furthermore, for these EAPIs, if the function is overridden, it
> >> | shall be a fatal error if the apply_user_patches command has not
> >> | been called at least once by the end of the phase.
> >> Wouldn't it make more sense to call apply_user_patches implicitly
> >> at the end of the phase, if it hasn't been called before?
> >> Otherwise, a call to that function would have to be added to every
> >> ebuild that defines src_prepare.
> > That was the point. The discussion on gentoo-dev suggested that "at
> > the end" is often the wrong place to put it, due to eautoreconf etc.
> > We need people to be explicit about where it goes.
> Yes, so apply_user_patches gives ebuilds the possibility to specify
> the exact place. I still think that a fallback to calling it at the
> end of the phase would be better than aborting with a fatal error.
Why? That error will only happen at most once, and users will never
> After all, this functionality is just a stop-gap measure for users to
> apply quick bug fixes, so I don't expect that it will be used very
> often. Even fewer cases will require that eautoreconf is called. Do we
> really want to force developers to put this function call into every
> ebuild? That would be out of proportion, IMHO.
"It not being used very often" is the key issue: developers are likely
to forget about it if they're not forced to remember. It's especially
complicated when eclasses are involved, so even if developers do
remember, they may not be sure whether they have to specify it in a
We can avoid a huge pile of "blah doesn't work properly with user
patches!" bugs here, essentially for free.