Gentoo Archives: gentoo-pms

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: gentoo-pms@l.g.o
Subject: Re: [gentoo-pms] apply_user_patches (was: EAPI 5 development branch)
Date: Mon, 07 May 2012 16:31:02
Message-Id: 20120507172809.44efea4d@googlemail.com
In Reply to: Re: [gentoo-pms] apply_user_patches (was: EAPI 5 development branch) by Ulrich Mueller
1 On Mon, 7 May 2012 17:17:10 +0200
2 Ulrich Mueller <ulm@g.o> wrote:
3 > >>>>> On Mon, 7 May 2012, Ciaran McCreesh wrote:
4 > > On Mon, 7 May 2012 02:12:14 +0200
5 > > Ulrich Mueller <ulm@g.o> wrote:
6 > >> | Furthermore, for these EAPIs, if the function is overridden, it
7 > >> | shall be a fatal error if the apply_user_patches command has not
8 > >> | been called at least once by the end of the phase.
9 > >>
10 > >> Wouldn't it make more sense to call apply_user_patches implicitly
11 > >> at the end of the phase, if it hasn't been called before?
12 > >>
13 > >> Otherwise, a call to that function would have to be added to every
14 > >> ebuild that defines src_prepare.
15 >
16 > > That was the point. The discussion on gentoo-dev suggested that "at
17 > > the end" is often the wrong place to put it, due to eautoreconf etc.
18 > > We need people to be explicit about where it goes.
19 >
20 > Yes, so apply_user_patches gives ebuilds the possibility to specify
21 > the exact place. I still think that a fallback to calling it at the
22 > end of the phase would be better than aborting with a fatal error.
23
24 Why? That error will only happen at most once, and users will never
25 see it.
26
27 > After all, this functionality is just a stop-gap measure for users to
28 > apply quick bug fixes, so I don't expect that it will be used very
29 > often. Even fewer cases will require that eautoreconf is called. Do we
30 > really want to force developers to put this function call into every
31 > ebuild? That would be out of proportion, IMHO.
32
33 "It not being used very often" is the key issue: developers are likely
34 to forget about it if they're not forced to remember. It's especially
35 complicated when eclasses are involved, so even if developers do
36 remember, they may not be sure whether they have to specify it in a
37 particular case.
38
39 We can avoid a huge pile of "blah doesn't work properly with user
40 patches!" bugs here, essentially for free.
41
42 --
43 Ciaran McCreesh

Attachments

File name MIME type
signature.asc application/pgp-signature