1 |
Ciaran McCreesh wrote: |
2 |
|
3 |
> On Tue, 19 Aug 2008 21:27:03 +0100 |
4 |
> Steve Long <slong@××××××××××××××××××.uk> wrote: |
5 |
>> > On Tue, 19 Aug 2008 23:31:17 +0530 |
6 |
>> > Arun Raghavan <ford_prefect@g.o> wrote: |
7 |
>> >> Ciaran McCreesh wrote: |
8 |
>> >> > The benefit is that it's a logically separate action, and will |
9 |
>> >> > avoid all the silliness of people repeatedly changing their |
10 |
>> >> > minds about which phase should do the eautoreconf calls and so |
11 |
>> >> > on. |
12 |
>> Er, that would be the new src_configure? |
13 |
> |
14 |
> Oh really? |
15 |
> |
16 |
Hmm fun as it isn't playing these games with you.. |
17 |
|
18 |
>> > In the grand scheme of things, no. In the grand scheme of things, |
19 |
>> > you only *need* a single src_ function. From a maintainer |
20 |
>> > convenience perspective, however, src_prepare is marginally more |
21 |
>> > useful than having a split src_configure. |
22 |
>> > |
23 |
>> How so? |
24 |
>> |
25 |
>> From a user point of view, and from a maintenance point of view, |
26 |
>> src_configure is very useful. |
27 |
> |
28 |
> Any reason you can provide for src_configure being useful can be used |
29 |
> with slight modification for src_prepare. |
30 |
> |
31 |
Which is no reason to add a new phase. OFC if zac wants to provide it that's |
32 |
entirely up to him. |
33 |
|
34 |
>> > It's a better mapping of the things ebuilds do than the current set |
35 |
>> > of functions. |
36 |
>> > |
37 |
>> > The logic is this: lots of ebuilds end up duplicating src_unpack |
38 |
>> > (or, in future EAPIs, calling 'default') and then adding things to |
39 |
>> > do preparation work. Experience suggests that the most common |
40 |
>> > reason for overriding src_unpack is to do preparation work, not to |
41 |
>> > change how things are unpacked. |
42 |
>> > |
43 |
>> Yeah I've always seen src_unpack as being more cogent to preparation |
44 |
>> of src files, than to actually untarring stuff. |
45 |
> |
46 |
> Yes, the 'unpack' in the name really does go along with the phase being |
47 |
> used to prepare things. |
48 |
> |
49 |
Oh so this is about correct nomenclature rather than anything else? I see. |
50 |
|
51 |
>> So what? Why make a new phase which every new dev has to know about, |
52 |
>> and we have to provide pre_ and post_ hooks for, when the existing |
53 |
>> phase covers the usage fine? |
54 |
> |
55 |
> Make a phase for each common logically distinct operation. Which, with |
56 |
> src_prepare being added, we almost have. |
57 |
> |
58 |
Yes, I see, because it's really needed; real functionality our users have |
59 |
been crying out for. |
60 |
|
61 |
> (The one missing is a src_fetch_extra or somesuch, for use by the scm |
62 |
> eclasses. But that wants special handling, and is probably best left to |
63 |
> another EAPI...) |
64 |
> |
65 |
Yes, a defined, configurable API for dealing with any version control would |
66 |
be useful, though your minion seemed to argue against it in #-portage. I |
67 |
can think of a couple of things that would be more useful to end-users: |
68 |
pkg_check for interactive ebuilds (eg license acceptance or media access), |
69 |
proper support for cross-compiling, integration of prefix, better handling |
70 |
of overlays, and of binpkgs.. |
71 |
|
72 |
>> > (Number-wise... For Exherbo, where the split's already been made, |
73 |
>> > custom src_prepare functions are three times more common than custom |
74 |
>> > src_unpack functions. And that figure's significantly lower than |
75 |
>> > what Gentoo would see, because with exheres-0 'default' functions |
76 |
>> > you don't need to write a src_prepare if you're merely applying |
77 |
>> > patches.) |
78 |
>> > |
79 |
>> Well it's easy enough to auto-apply patches, given a declaration in |
80 |
>> the ebuild (since files for all versions are in the same dir.) It |
81 |
>> certainly doesn't need a new phase. |
82 |
> |
83 |
> Well, if you're proposing that Gentoo also adopts the more complicated |
84 |
> default_* functions from exheres-0, you're more than welcome to write |
85 |
> up a proposal... |
86 |
> |
87 |
Tsk of course not. default functions are in the pipeline in any case, but |
88 |
glad to see you're still using this list for proselytising your pet project |
89 |
while avoiding true discussion. In any event, it wouldn't be needed. |
90 |
|
91 |
>> >> The *only* potential "benefit" I see here is that at some point of |
92 |
>> >> time in the nebulous future, it might be possible to tell the PM to |
93 |
>> >> always skip src_prepare in order to give a system where everything |
94 |
>> >> is "vanilla". |
95 |
>> > |
96 |
>> > Such a system wouldn't be usable... Not all of Gentoo's patches are |
97 |
>> > non-essential. |
98 |
>> > |
99 |
>> So the real, fully-defined, explicit benefit is.. |
100 |
> |
101 |
> The same as the benefit of splitting src_compile into src_configure and |
102 |
> src_compile, except that it'll be of use to a slightly larger |
103 |
> proportion of ebuilds. |
104 |
> |
105 |
As ever, you fail to argue the actual case, preferring to hide behind "the |
106 |
same reasons as.." which is a variant on the "if you don't understand some |
107 |
one line comment, you're not qualified to discuss anything (plus you're |
108 |
ugly.)" |
109 |
|
110 |
The reasoning others have given (yes it is possible to explain why without |
111 |
making people read thru 20 one line emails) is that this would be useful |
112 |
for live ebuilds. In maintenance terms (when looking at the lifecycle of an |
113 |
ebuild) I don't see the need, since there is no unpacking required from a |
114 |
vcs pull. Once it's made into a normal ebuild, any preparation would |
115 |
necessarily require review and might not be needed at all. |
116 |
|
117 |
Call the function what you like (or add a new phase with the hooks) it's |
118 |
still logically one point in time. For a live ebuild it's to prepare the |
119 |
src, for a normal one to (possibly) unpack and prepare. |
120 |
|
121 |
src_configure is a logically distinct action which warrants a new phase, |
122 |
since the e*conf call in compile makes retrying a long build (without |
123 |
having to recompile stuff which doesn't need it) much more difficult; its |
124 |
absence prevents full use of make. Prepare does not warrant a new phase imo |
125 |
since it should only be run once per compilation instance; anything it does |
126 |
can either be done in unpack, or in configure should that be more useful. |