1 |
2009/5/28 Joe Peterson <lavajoe@g.o>: |
2 |
> Alec Warner wrote: |
3 |
>>> No, it's entirely objective. GLEP 55 clearly shows how the filename |
4 |
>>> based options are objectively better than anything else. |
5 |
>> |
6 |
>> But the decision will not be based entirely on objective merits |
7 |
>> (although I will concede that EAPI in filename is the 'best' technical |
8 |
>> choice). |
9 |
> |
10 |
> (Jeez, I hate to add another to this thread, but this way of defining |
11 |
> 'technical' bothers me) |
12 |
> |
13 |
> Along the lines of what Roy so eloquently expressed, I think it's |
14 |
> important that we do not divorce *design* from *technical*. The |
15 |
> decision of where to place the EAPI is a design issue, and many of us |
16 |
> here clearly believe that it is *not* good design to put this kind of |
17 |
> metadata in the filename. Therefore, the statement that it is the |
18 |
> 'best' technical choice is not objectively true. |
19 |
> |
20 |
> Technical issues of performance and efficiency can be addressed when |
21 |
> proper design has been done beforehand. Part of the purpose of the |
22 |
> implementation (after proper design is in place) is to address |
23 |
> performance and other related issues. And part of the design is how we |
24 |
> define the *interface*. The filename is clearly part of the interface. |
25 |
> It is part of how devs (and users) interact with portage when writing |
26 |
> ebuilds. Much of the argument for EAPI in the filename has been |
27 |
> motivated by a perceived implementation benefit of speed, as if there |
28 |
> were no other solutions (which is naive). As Roy suggested, if all |
29 |
> engineering decisions were based purely on pragmatic "ease of |
30 |
> implementation" factors, we'd have a lot of ugly designs/interfaces out |
31 |
> there. |
32 |
> |
33 |
> It may be easy (although incorrect) to dismiss elegance/design/interface |
34 |
> issues as "non-technical", but I maintain they actually *are* technical |
35 |
> matters of great importance. I've been an engineer for over 20 years, |
36 |
> and I have seen the pitfalls of taking the quick-and-dirty approach just |
37 |
> to slap a new feature into a software app. I've seen how such hasty |
38 |
> design mistakes can cause great pain and regret for a long time after. |
39 |
> Let's get the design right, first. For what it's worth, GLEP 55 does |
40 |
> now provide an option (#3: Easily fetchable EAPI inside the ebuild and |
41 |
> one-time extension change) that demonstrates good design. |
42 |
|
43 |
I think what you are missing is that some people (me included) think |
44 |
that the in-file approach is the cleanest and most obvious solution |
45 |
(which also happens to not hurt performance). So if you want "bad |
46 |
design" to be an objective argument you need to back it up with |
47 |
something concrete. For example, could you foresee any actual problems |
48 |
of the in-filename approach? Cause all I was hearing was "it doesn't |
49 |
look nice" which now is "oh no, don't expose metadata". The former is |
50 |
clearly subjective and the latter is already done ($PN-$PV) and |
51 |
doesn't seem to cause any problems. |
52 |
|
53 |
-- |
54 |
Best Regards, |
55 |
Piotr Jaroszyński |