1 |
Donnie Berkholz wrote: |
2 |
> On 11:12 Sun 08 Jun , Piotr Jaroszyński wrote: |
3 |
>> looks like every nominee wants the council to be more technical so I |
4 |
>> have a few technical questions for you: |
5 |
>> |
6 |
>> 1. GLEP54 |
7 |
>> 2. GLEP55 |
8 |
> |
9 |
> I don't have any particular objections to these, besides the vague |
10 |
> aesthetic one of having EAPI in the filename. Particularly long, weird |
11 |
> EAPIs filled with special characters (to which some will reply "So don't |
12 |
> do that"). |
13 |
|
14 |
Donnie, I agree, and I think it would be a mistake to use the filename |
15 |
extension for the EAPI number, even for simple "non-long-or-funky" |
16 |
EAPIs. I know that my reasons will be considered, by some, to be |
17 |
irrelevant (especially since aesthetics and/or style/elegance are of less |
18 |
importance to some), but I really think this should be carefully considered; |
19 |
a mistake here would be quite a shame. I'll state again (slightly modified) |
20 |
what I wrote a while back on this issue. |
21 |
|
22 |
Technical reasons to avoid the filename: |
23 |
|
24 |
1) Increase of [needless] complexity in filenames/extensions (and only one |
25 |
example of the impact is that searching for ebuild files becomes less |
26 |
straightforward), when things like SLOT, EAPI, etc., etc., seem to |
27 |
naturally belong as part of the script contents/syntax. |
28 |
2) Having the same info in more than one place is generally a bad idea in |
29 |
any design - this is true in any discipline. I don't care how many people |
30 |
say a) that this is not an issue or b) that it's "not a duplication", |
31 |
in every data system I've worked on, it has been a very bad idea to have |
32 |
more than one version of the same info that can get out of sync with each |
33 |
other. Even if you take great care, I'd still always want to check both |
34 |
and not trust either version of the info blindly. Caching or hashing is |
35 |
different (i.e. where the caching mechanism is robust), since the |
36 |
system itself keeps the cache up to date, and one version of the info |
37 |
is strictly derived from the other rather than both being the source. |
38 |
3) It uses the extension in a way that goes against common use in computers, |
39 |
especially *nix. No longer could we then say that a file of type |
40 |
"Gentoo ebuild" has the extension "ebuild" |
41 |
(simple/straightforward/standard). |
42 |
4) It seems that the motivation for this GLEP is so that the tools can |
43 |
determine the EAPI without reading/sourcing the script. In order to |
44 |
get around this, the GLEP suggests exposing this technical information |
45 |
in the filename. This is the wrong place to expose it, and the reasons |
46 |
given are not that this detail should be exposed there but rather because |
47 |
it is inefficient to source the file to get the info. So this is a case |
48 |
of trying to solve a technical issue by changing the interface. I |
49 |
believe it would be more correct to attack the technical problem in a way |
50 |
that does not do this, and I am sure this can be solved. |
51 |
|
52 |
Other reasons: |
53 |
|
54 |
1) Littering the filename with this kind of stuff is potentially confusing to |
55 |
both devs and users - I know it's been stated that users shouldn't care, |
56 |
but I don't think that's a good reason/assumption. |
57 |
2) It is not an elegant filename policy. Many systems have elegance as |
58 |
a design goal. |
59 |
3) Assuming going this route is a mistake, it could be hard to reverse. |
60 |
|
61 |
Currently, I consider Gentoo's ebuild filename conventions simple and |
62 |
elegant. In fact, it is beautifully done. I'd hate to see this go down the |
63 |
wrong path now. |
64 |
|
65 |
-Joe |
66 |
|
67 |
-- |
68 |
gentoo-dev@l.g.o mailing list |