1 |
hasufell: |
2 |
> Sergey Popov: |
3 |
>> 18.08.2014 16:04, hasufell пишет: |
4 |
>>>> You have my strong opposition on such change as well. It will turn |
5 |
>>>> ebuilds into unreadable and undpredictable mess, please do not do that |
6 |
>>>> |
7 |
>>> |
8 |
>>> They are already fairly unreadable and unpredictable. |
9 |
>>> |
10 |
>> |
11 |
>> For you - maybe. But not for me. |
12 |
>> |
13 |
>> I am NOT talking about hacks like putting additional *.as files through |
14 |
>> echo(hello Boost ebuild) or doing something crazy with subshells. |
15 |
>> |
16 |
>> But most of the eclass and ebuilds are readable quite simple if you read |
17 |
>> devmanual, PMS and have a brain. |
18 |
>> |
19 |
>> Of course, there are sometimes non-trivial stuff that is hard to read. |
20 |
>> |
21 |
>> But majority of ebuilds and eclasses are fine to understand and predict. |
22 |
>> |
23 |
>> So, without examples from you, this discussion will lead to nowhere, so, |
24 |
>> please let's stop it. |
25 |
>> |
26 |
> |
27 |
> From my time as a sunrise dev I strongly disagree. People have problems |
28 |
> with understanding the mess, including actual programmers. They have |
29 |
> enough technical understanding, but not the time or motivation to go |
30 |
> through all those funny pitfalls which are NOT properly documented in |
31 |
> devmanual. |
32 |
> |
33 |
> The most popular example is what we are talking about right now: |
34 |
> indirect inheritance for example via games.eclass which inherits |
35 |
> base.eclass but does not export src_unpack so stuff like unpacker.eclass |
36 |
> and git-2.eclass will likely just do nothing if you inherit them before |
37 |
> games.eclass (which is required by games herd policy)... uhm. I doubt |
38 |
> you would have guessed this one if you saw the plain ebuild. I know the |
39 |
> pitfall, so I see it just from looking at the inherit line. But it is |
40 |
> far from being obvious. |
41 |
> |
42 |
|
43 |
Even more interesting... you can work around this by inheriting |
44 |
base.eclass explicitly before e.g. unpacker.eclass, something like |
45 |
|
46 |
inherit base unpacker games |
47 |
|
48 |
=> unpacker_src_unpack() is carried out by default (and the ebuild |
49 |
breaks if someone thinks the base.eclass is useless and removes it) |
50 |
|
51 |
inherit unpacker games |
52 |
|
53 |
=> unpacker_src_unpack is not carried out by default although |
54 |
games.eclass does not directly overwrite it |
55 |
|
56 |
If you think any of this is sensible... |