1 |
On Tue, 19 Aug 2008 21:27:03 +0100 |
2 |
Steve Long <slong@××××××××××××××××××.uk> wrote: |
3 |
> > On Tue, 19 Aug 2008 23:31:17 +0530 |
4 |
> > Arun Raghavan <ford_prefect@g.o> wrote: |
5 |
> >> Ciaran McCreesh wrote: |
6 |
> >> > The benefit is that it's a logically separate action, and will |
7 |
> >> > avoid all the silliness of people repeatedly changing their |
8 |
> >> > minds about which phase should do the eautoreconf calls and so |
9 |
> >> > on. |
10 |
> Er, that would be the new src_configure? |
11 |
|
12 |
Oh really? |
13 |
|
14 |
> > In the grand scheme of things, no. In the grand scheme of things, |
15 |
> > you only *need* a single src_ function. From a maintainer |
16 |
> > convenience perspective, however, src_prepare is marginally more |
17 |
> > useful than having a split src_configure. |
18 |
> > |
19 |
> How so? |
20 |
> |
21 |
> From a user point of view, and from a maintenance point of view, |
22 |
> src_configure is very useful. |
23 |
|
24 |
Any reason you can provide for src_configure being useful can be used |
25 |
with slight modification for src_prepare. |
26 |
|
27 |
> > It's a better mapping of the things ebuilds do than the current set |
28 |
> > of functions. |
29 |
> > |
30 |
> > The logic is this: lots of ebuilds end up duplicating src_unpack |
31 |
> > (or, in future EAPIs, calling 'default') and then adding things to |
32 |
> > do preparation work. Experience suggests that the most common |
33 |
> > reason for overriding src_unpack is to do preparation work, not to |
34 |
> > change how things are unpacked. |
35 |
> > |
36 |
> Yeah I've always seen src_unpack as being more cogent to preparation |
37 |
> of src files, than to actually untarring stuff. |
38 |
|
39 |
Yes, the 'unpack' in the name really does go along with the phase being |
40 |
used to prepare things. |
41 |
|
42 |
> So what? Why make a new phase which every new dev has to know about, |
43 |
> and we have to provide pre_ and post_ hooks for, when the existing |
44 |
> phase covers the usage fine? |
45 |
|
46 |
Make a phase for each common logically distinct operation. Which, with |
47 |
src_prepare being added, we almost have. |
48 |
|
49 |
(The one missing is a src_fetch_extra or somesuch, for use by the scm |
50 |
eclasses. But that wants special handling, and is probably best left to |
51 |
another EAPI...) |
52 |
|
53 |
> > (Number-wise... For Exherbo, where the split's already been made, |
54 |
> > custom src_prepare functions are three times more common than custom |
55 |
> > src_unpack functions. And that figure's significantly lower than |
56 |
> > what Gentoo would see, because with exheres-0 'default' functions |
57 |
> > you don't need to write a src_prepare if you're merely applying |
58 |
> > patches.) |
59 |
> > |
60 |
> Well it's easy enough to auto-apply patches, given a declaration in |
61 |
> the ebuild (since files for all versions are in the same dir.) It |
62 |
> certainly doesn't need a new phase. |
63 |
|
64 |
Well, if you're proposing that Gentoo also adopts the more complicated |
65 |
default_* functions from exheres-0, you're more than welcome to write |
66 |
up a proposal... |
67 |
|
68 |
> >> The *only* potential "benefit" I see here is that at some point of |
69 |
> >> time in the nebulous future, it might be possible to tell the PM to |
70 |
> >> always skip src_prepare in order to give a system where everything |
71 |
> >> is "vanilla". |
72 |
> > |
73 |
> > Such a system wouldn't be usable... Not all of Gentoo's patches are |
74 |
> > non-essential. |
75 |
> > |
76 |
> So the real, fully-defined, explicit benefit is.. |
77 |
|
78 |
The same as the benefit of splitting src_compile into src_configure and |
79 |
src_compile, except that it'll be of use to a slightly larger |
80 |
proportion of ebuilds. |
81 |
|
82 |
-- |
83 |
Ciaran McCreesh |