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