| 1 |
Ciaran McCreesh wrote: |
| 2 |
|
| 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 avoid |
| 7 |
>> > all the silliness of people repeatedly changing their minds about |
| 8 |
>> > which phase should do the eautoreconf calls and so on. |
| 9 |
Er, that would be the new src_configure? |
| 10 |
|
| 11 |
>> |
| 12 |
>> a) Is this really an issue for maintainers? |
| 13 |
> |
| 14 |
> It's not a huge issue, any more than src_configure is. Equally, it's not |
| 15 |
> expensive to implement. |
| 16 |
> |
| 17 |
>> b) Does it really matter? |
| 18 |
> |
| 19 |
> In the grand scheme of things, no. In the grand scheme of things, you |
| 20 |
> only *need* a single src_ function. From a maintainer convenience |
| 21 |
> perspective, however, src_prepare is marginally more useful than having |
| 22 |
> a split src_configure. |
| 23 |
> |
| 24 |
How so? |
| 25 |
|
| 26 |
From a user point of view, and from a maintenance point of view, |
| 27 |
src_configure is very useful. |
| 28 |
|
| 29 |
>> c) So the flow will look like: |
| 30 |
>> |
| 31 |
>> ... |
| 32 |
>> src_unpack |
| 33 |
>> src_prepare |
| 34 |
>> src_configure |
| 35 |
>> src_compile |
| 36 |
>> ... |
| 37 |
>> |
| 38 |
>> To me this seems like an unnecessary overgeneralisation. |
| 39 |
> |
| 40 |
> It's a better mapping of the things ebuilds do than the current set of |
| 41 |
> functions. |
| 42 |
> |
| 43 |
> The logic is this: lots of ebuilds end up duplicating src_unpack (or, |
| 44 |
> in future EAPIs, calling 'default') and then adding things to do |
| 45 |
> preparation work. Experience suggests that the most common reason for |
| 46 |
> overriding src_unpack is to do preparation work, not to change how |
| 47 |
> things are unpacked. |
| 48 |
> |
| 49 |
Yeah I've always seen src_unpack as being more cogent to preparation of src |
| 50 |
files, than to actually untarring stuff. So what? Why make a new phase |
| 51 |
which every new dev has to know about, and we have to provide pre_ and |
| 52 |
post_ hooks for, when the existing phase covers the usage fine? |
| 53 |
|
| 54 |
> (Number-wise... For Exherbo, where the split's already been made, |
| 55 |
> custom src_prepare functions are three times more common than custom |
| 56 |
> src_unpack functions. And that figure's significantly lower than what |
| 57 |
> Gentoo would see, because with exheres-0 'default' functions you don't |
| 58 |
> need to write a src_prepare if you're merely applying patches.) |
| 59 |
> |
| 60 |
Well it's easy enough to auto-apply patches, given a declaration in the |
| 61 |
ebuild (since files for all versions are in the same dir.) It certainly |
| 62 |
doesn't need a new phase. |
| 63 |
|
| 64 |
>> The *only* potential "benefit" I see here is that at some point of |
| 65 |
>> time in the nebulous future, it might be possible to tell the PM to |
| 66 |
>> always skip src_prepare in order to give a system where everything is |
| 67 |
>> "vanilla". |
| 68 |
> |
| 69 |
> Such a system wouldn't be usable... Not all of Gentoo's patches are |
| 70 |
> non-essential. |
| 71 |
> |
| 72 |
So the real, fully-defined, explicit benefit is.. |
Archives