1 |
Ciaran McCreesh wrote: |
2 |
|
3 |
> On Thu, 13 Aug 2009 19:22:16 +0100 |
4 |
> Steven J Long <slong@××××××××××××××××××.uk> wrote: |
5 |
>> > PMS accurately reflects the Portage documentation and the commit |
6 |
>> > message that introduced the feature -- it's purely for use |
7 |
>> > in /etc/portage/, which is beyond the scope of PMS. |
8 |
>> > |
9 |
>> If it's pre-EAPI it's part of EAPI '0'. That you neglected to |
10 |
>> document it, for whatever reason, is irrelevant. |
11 |
> |
12 |
> No, it's not part of EAPI 0. |
13 |
If it's a feature that is pre-PMS, it's part of EAPI-0. The definition is |
14 |
flexible, presumably to avoid this kind of runaround. |
15 |
|
16 |
> It's an accident. If you'd like another |
17 |
> example of an accident, Portage won't complain if you stick garbage in |
18 |
> certain metadata keys; this does not mean PMS should say that it's |
19 |
> legal to put garbage in metadata keys. |
20 |
> |
21 |
That's irrelevant and you know it, apart from being one of your usual |
22 |
political digs at portage. |
23 |
|
24 |
>> > It is not the business of PMS to enforce undocumented features |
25 |
>> It's not undocumented, as you just pointed out above. |
26 |
> |
27 |
> Using it in the tree is undocumented. |
28 |
But it's not an "undocumented feature" is it? |
29 |
|
30 |
> Using it in user configuration is beyond the scope of PMS. |
31 |
Define 'user' |
32 |
|
33 |
>> > that Portage supports only by accident |
34 |
>> Oh, so now you know the minds of the portage developers? |
35 |
> |
36 |
> Yes. |
37 |
No, you clearly do not, as this shows: |
38 |
|
39 |
> I know that they said when adding the directory feature that it |
40 |
> was for use in user configuration files. That's what the commit message |
41 |
> said, and that's what the documentation patch said. The documentation |
42 |
> change explicitly only allowed the feature in user configuration, not |
43 |
> the tree. |
44 |
> |
45 |
> Had the feature intended to be tree-usable, the documentation change |
46 |
> would have said so. |
47 |
> |
48 |
Thanks for explaining what "the Portage documentation and the commit |
49 |
message" means. And yeah, you can read it. Well done. It *does not* mean you |
50 |
know what future directions might have been envisaged. |
51 |
|
52 |
<snip> |
53 |
>> > and that aren't used in the tree. |
54 |
>> |
55 |
>> Circular argument, don't you think? It's not in-tree so we won't put |
56 |
>> it in PMS. It's not in PMS, so it's not allowed in-tree. |
57 |
> |
58 |
> That's only a circular argument if you snip out the rest of the |
59 |
> sentence. |
60 |
> |
61 |
Nonsense. You gave the fact that it's not used in the tree as a reason not |
62 |
to put it in PMS, did you not? I merely addressed it separately, since it |
63 |
is a distinct semantic component. |
64 |
|
65 |
>> I'd like to ask the Council to consider whether EAPI development has |
66 |
>> not in fact supplanted a large part of the GLEP process (specifically |
67 |
>> the technical aspects to do with ebuild development.) As such, |
68 |
>> insisting on all discussion on bugzilla is in fact a subversion of |
69 |
>> the original process that people have agreed upon. |
70 |
> |
71 |
> Moving the discussion to bugzilla was the Council's decision, not mine. |
72 |
> |
73 |
Yes, well, I didn't ask you. I asked the Council to consider the broader |
74 |
picture, which is their role, since effectively GLEPs are now only for |
75 |
non-technical things, or might as well be, since all future ebuild |
76 |
directions are EAPI by definition. Having wider input (which is what this |
77 |
list is for) might avoid future blind-alleys. |
78 |
|
79 |
Nevertheless, I'm sure they'll take your valuable insight under |
80 |
consideration, as well as the history and any lobbying that might have gone |
81 |
on at the time, assuming they were around and haven't suppressed the |
82 |
memory. |
83 |
|
84 |
-- |
85 |
#friendly-coders -- We're friendly but we're not /that/ friendly ;-) |