1 |
On Wed, 28 Dec 2011 19:36:01 -0800 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
|
4 |
> People have problems as is dealing w/ eclasses changing and their |
5 |
> dependencies in external repositories not being updated; this |
6 |
> complicates that issue and introduces the same potential into |
7 |
> gentoo-x86 itself. That's not beneficial. |
8 |
|
9 |
I agree with nearly all of that: introducing changes to an eclass |
10 |
usually means going through the whole tree and fixing what breaks. |
11 |
That's a lot more easy to fix than adding more layers of indirection |
12 |
based on a variable's value and adjusting the value according to the |
13 |
time the ebuild was written versus when the eclass was changed. |
14 |
|
15 |
> Thing to keep in mind beyond the potential for confusion the |
16 |
> proposals entail were they implemented, is the implementation |
17 |
> itself. Timeslices? python eclass api versions (when people have |
18 |
> problems figuring out the existing, *singular* version)? These |
19 |
> things aren't going to be simple which means more than likely, |
20 |
> they're going to break, and more than likely it's going to be a PITA |
21 |
> to maintain it. |
22 |
|
23 |
Last time I took tranquilisers and set myself up to read python.eclass, |
24 |
I found that it still doesn't break at 80 characters. Apparently even |
25 |
that can't be fixed in a timely fashion. |
26 |
|
27 |
Assing even more layers of mystification like: |
28 |
|
29 |
if [[ PYTHON_ECLASS_API = 2 ]]; then |
30 |
python_pkg_setup() { |
31 |
|
32 |
or even: |
33 |
|
34 |
python_pkg_setup() { |
35 |
if [[ PYTHON_ECLASS_API = 2 ]]; then |
36 |
|
37 |
would be insane, in my opinion. |
38 |
|
39 |
Also, from the perspective of an ebuild writer, setting |
40 |
|
41 |
PYTHON_ECLASS_API=2 |
42 |
inherit python |
43 |
|
44 |
would be meaningless lacking a very clear description of what the |
45 |
number 2 means. |
46 |
|
47 |
|
48 |
jer |