1 |
Ciaran McCreesh wrote: |
2 |
>> > c) It's an extremely bizarre restriction, the likes of which do not |
3 |
>> > currently exist, that will confuse the hell out of all the people |
4 |
>> > that don't realise that such a restriction exists. |
5 |
>> |
6 |
I don't think it's that hard to understand "You can only set EAPI *once* in |
7 |
your ebuild." Are you really saying devs won't get that? |
8 |
|
9 |
Who are these mythical "people"? Devs take a quiz: the EAPI setting |
10 |
restrictions can easily be added to it, as well as being documented |
11 |
elsewhere. |
12 |
|
13 |
That would of course have to be done doubly so for your GLEP, which imposes |
14 |
a much more bizarre restriction: that the EAPI must go in the filename. |
15 |
|
16 |
>> Devs are already used to follow numerous conventions in the way they |
17 |
>> format their ebuilds. |
18 |
> |
19 |
> And they already arbitrarily don't follow them. We get people screwing |
20 |
> up whitespace and brackets in dep strings, for example (Portage doesn't |
21 |
> error check these very well). |
22 |
> |
23 |
Odd: I found repoman very fussy about those. Leaving the digs at portage |
24 |
aside, that's what the new commit reviews are about. |
25 |
|
26 |
>> > d) It introduces a new prepass parse layer to an already complex |
27 |
>> > process. |
28 |
>> |
29 |
>> Both solutions add some new steps to this process, and it doesn't look |
30 |
>> to me like there's a significant difference beetween their respective |
31 |
>> added complexity. That said, you're the PM dev here, not me, so if |
32 |
>> you confirm that implementation of an in-contents solution is |
33 |
>> significantly harder, then i will accept the argument. |
34 |
> |
35 |
> It's not harder (assuming the syntax is well defined -- single, double |
36 |
> or no quotes? export? leading whitespace? is it the first or the last |
37 |
> match of EAPI="" that's taken?). It's just messy, because we'd have to |
38 |
> deal with stupid cases like: |
39 |
> |
40 |
> DESCRPTION="Config file to make Paludis support |
41 |
> EAPI='4' packages" |
42 |
> |
43 |
Wow, yet another contrived b0rkage. You really don't have a very high |
44 |
opinion of Gentoo devs, do you? |
45 |
|
46 |
> EAPI="1" |
47 |
> export EAPI=2 |
48 |
> |
49 |
> src_compile() { |
50 |
> cat <<END > somefile |
51 |
> EAPI=3 |
52 |
> END |
53 |
> } |
54 |
> |
55 |
All those would be dealt with by the well-defined syntax. I'd start with: |
56 |
EAPI="foo" on its own on a line. The first setting is taken. |
57 |
|
58 |
>> > e) The Portage guys said no to it. |
59 |
>> |
60 |
>> When/where? I've only seen Marius commenting here, but not on that |
61 |
>> aspect. Also, i've read this 2005 "EBUILD_FORMAT" discussion that |
62 |
>> Steve Long has pointed [1], where Brian was against non-Bash parsing, |
63 |
>> but: |
64 |
>> - he was against changing files extension too, |
65 |
>> - the flaws in the EAPI system designed at this time is what led to |
66 |
>> rethinking it now. |
67 |
>> |
68 |
>> If i've missed something since then (and that's likely), could you |
69 |
>> give me a pointer to the archives? Thanks. |
70 |
> |
71 |
> A while after that Brian and I had a huge lengthy argument on IRC about |
72 |
> it. I don't have IRC logs that far back, which is kind of a shame |
73 |
> because we covered pretty much all of the things that people are |
74 |
> moaning about now... |
75 |
> |
76 |
Somehow I'm not reading "Brian and I agreed that.." and it concerns me that |
77 |
we haven't so far had portage and pkgcore devs chiming in that your GLEP is |
78 |
just what they want as the solution to several issues, meriting the work |
79 |
required to change over, and the future hackiness and restrictions it |
80 |
imposes. |
81 |
|
82 |
>> My point here is that the in-contents alternative is just a syntaxic |
83 |
>> rule which defines a first-pass extraction of a value from an ebuild |
84 |
>> file (as opposed to an ebuild file name extension). How it is then |
85 |
>> used (what the "eapi" function does, if anything, or whether this |
86 |
>> value is the definitive EAPI, or how EAPI vs. eclasses is handled, |
87 |
>> etc.) can be subject to future changes depending on this value. That's |
88 |
>> part of why this solution is not more restrictive than the file name |
89 |
>> extension approach. |
90 |
> |
91 |
> But then you get the highly weird result of setting, say, EAPI="4" in |
92 |
> the ebuild but the c/p-v actually having EAPI="3" because of weird hard |
93 |
> to see behind the scenes eclass voodoo. |
94 |
That sounds like a borked package manager, and something which should not be |
95 |
allowed per the spec. If an ebuild author sets EAPI that's what the |
96 |
metadata EAPI must reflect. |
97 |
|
98 |
> That's equivalent to the "using |
99 |
> the wrong file extension and then overriding with a variable" |
100 |
> situation, except that you're effectively requiring it for future |
101 |
> changes rather than making it something that's a big flashy warning. |
102 |
> |
103 |
Or you're just contriving examples. |
104 |
|
105 |
> (From a technical perspective, changing EAPI mid-source is a massive |
106 |
> pain in the ass. EAPI pretty much has to be able to tinker with PATH |
107 |
> and friends, and there's no sane way of modifying variables as soon as |
108 |
> another variable changes. |
109 |
It's up to the eclass/ebuild author to deal with the consequences of code |
110 |
they write. In the same light, it's up to the PM devs to ensure that the |
111 |
EAPIs they support work correctly. |
112 |
|
113 |
> For example, and not saying that this |
114 |
> specific case is desirable, EAPI foo could require that the first 'sed' |
115 |
> in PATH be GNU sed, whilst EAPI bar could require that it be the normal |
116 |
> system sed.) |
117 |
> |
118 |
If you could come up with a more cogent example (that actually poses a |
119 |
technical challenge) perhaps your peers can help you with the difficulties |
120 |
you are having. That's what a dev mailing list is for. |
121 |
|
122 |
|
123 |
-- |
124 |
gentoo-dev@g.o mailing list |