1 |
pioto@×××××.org wrote: |
2 |
>> 1) Increase of [needless] complexity in filenames/extensions (and only one |
3 |
>> example of the impact is that searching for ebuild files becomes less |
4 |
>> straightforward), when things like SLOT, EAPI, etc., etc., seem to |
5 |
>> naturally belong as part of the script contents/syntax. |
6 |
> |
7 |
> Okay... so: |
8 |
> find /usr/portage -name *ebuild |
9 |
> |
10 |
> becomes: |
11 |
> find /usr/portage -name *ebuild* |
12 |
> |
13 |
> That doesn't seem that much harder to me... Same for the file detection |
14 |
> for editors. |
15 |
|
16 |
I'm not saying it's a lot harder. But it is more complex and less |
17 |
elegant. Also, it is error-prone. If someone, by habit, looks for all |
18 |
"*.ebuild", he will miss a portion of the ebuilds and not even realize |
19 |
it at first (or ever). |
20 |
|
21 |
>> 2) Having the same info in more than one place is generally a bad idea in |
22 |
>> any design - this is true in any discipline. [...] |
23 |
> |
24 |
> If you read the proposal more closely, you would notice that it |
25 |
> specifically says to *not* specify EAPI in more than one place. It belongs |
26 |
> solely in the filename suffix. The only reason the EAPI variable would be |
27 |
> recognized inside the file itself is to allow for backwards compatibility |
28 |
> with the current way EAPI=1 is done -- this behavior would be discouraged |
29 |
> in all future ebuilds. |
30 |
|
31 |
Still, the GLEP addresses the very point of what logic has to be |
32 |
followed if the EAPI exists in the filename, in the file, or both. It |
33 |
talks of "pre-source" EAPIs and "post-source" EAPIs. Complicated. |
34 |
|
35 |
>> 3) It uses the extension in a way that goes against common use in computers, |
36 |
>> especially *nix. No longer could we then say that a file of type |
37 |
>> "Gentoo ebuild" has the extension "ebuild" |
38 |
>> (simple/straightforward/standard). |
39 |
> |
40 |
> In most unixes, the file extension is completely meaningless. What matters |
41 |
> is the contents of the file. Nautilus, etc, mostly use detection based |
42 |
> upon the files contents to identify file types (at least for local files), |
43 |
> not file extensoins. |
44 |
|
45 |
That wasn't the point I was trying to make. I am not saying that the |
46 |
extension has special meaning (even the "." has no meaning, really, in |
47 |
unix) to software. I mean that people associate certain types of files |
48 |
with certain extensions. I'm speaking more of the human interface here. |
49 |
|
50 |
>> 4) It seems that the motivation for this GLEP is so that the tools can |
51 |
>> determine the EAPI without reading/sourcing the script. In order to |
52 |
>> get around this, the GLEP suggests exposing this technical information |
53 |
>> in the filename. This is the wrong place to expose it, and the reasons |
54 |
>> given are not that this detail should be exposed there but rather because |
55 |
>> it is inefficient to source the file to get the info. So this is a case |
56 |
>> of trying to solve a technical issue by changing the interface. I |
57 |
>> believe it would be more correct to attack the technical problem in a way |
58 |
>> that does not do this, and I am sure this can be solved. |
59 |
> |
60 |
> The reason for this is that, while the current two EAPIs don't cause |
61 |
> trouble if you try to source them when you don't support them, that |
62 |
> doesn't mean future ones won't. I'm not talking about anything silly like |
63 |
> rewriting ebuilds in python, but things like changing syntax for DEPEND |
64 |
> could potentially confuse older package managers. By adding the EAPI |
65 |
> specification to the filename instead, old package managers just plain |
66 |
> won't see packages they don't understand, so there's no need to worry |
67 |
> about this. |
68 |
|
69 |
Well, in general, if you rely on extensions changing every time a |
70 |
program cannot deal with a new feature of a file format, it would be |
71 |
quite crazy. For example, if C programs had to start using ".c-2", |
72 |
".c-3", etc., it would get ugly fast. Also, it is easy to build EAPI |
73 |
checking into portage now, and when the requisite time passes, you only |
74 |
need to deal with situations where *very* old portage versions are still |
75 |
in use. Since portage is typically the first thing the system upgrades |
76 |
after a sync, I don't see a big issue. Or, if that is not acceptable, |
77 |
see my comment at the end about a one-time change to a new extension |
78 |
like ".eb". |
79 |
|
80 |
> Also, sourcing a package to extract one metadata key takes much more time |
81 |
> than just not loading it in the first place. |
82 |
|
83 |
I understand there are technical/performance issues to solve, but this |
84 |
does not, IMHO, justify moving this info into a filename/extension. |
85 |
|
86 |
>> 1) Littering the filename with this kind of stuff is potentially confusing to |
87 |
>> both devs and users - I know it's been stated that users shouldn't care, |
88 |
>> but I don't think that's a good reason/assumption. |
89 |
> |
90 |
> New eapis aren't necessarily of any immediate use to people. Those who |
91 |
> don't see the need for them can continue to just use EAPI=0, plain old |
92 |
> .ebuild files of the sort that've been around for years, and for many |
93 |
> packages this is totally appropriate. The only devs who should care are |
94 |
> the ones who have a need for the new features. |
95 |
|
96 |
But when they do need the new features, they need to use the new EAPIs. |
97 |
This is not a matter of "degree" - it is a matter of defining the |
98 |
filename format. Once you allow freeform ".ebuild-????" extensions, |
99 |
everyone has to deal with the possibility of their existence. |
100 |
|
101 |
> Users shouldn't ever have to read the ebuild files themselves. The package |
102 |
> manager should tell them everything they need to know. |
103 |
|
104 |
It doesn't matter, users still will look at the builds and the |
105 |
directories they are in. And I am sure many users do this regularly. |
106 |
We are not hiding the details of the files and filenames in an opaque |
107 |
database where none of this would matter (we're not MicroSoft, after all |
108 |
:). What Gentoo proudly calls the main portage tree is out there for |
109 |
all to see and examine, which is a good thing. |
110 |
|
111 |
But what users *really* don't care about is EAPIs, and this GLEP would |
112 |
expose that technical detail to them in a very blatent way. |
113 |
|
114 |
Everything else in the filename is something portage exposes to them in |
115 |
its interface (category, package, version, revision, etc.), so this |
116 |
would be the first thing in the filename that would *not* match up with |
117 |
something we want to expose to users. EAPI is really something that |
118 |
should be under the hood. |
119 |
|
120 |
>> 2) It is not an elegant filename policy. Many systems have elegance as |
121 |
>> a design goal. |
122 |
> |
123 |
> That's a matter of opinion. It seems perfectly elegant to me -- not to |
124 |
> mention the various, rather clear technical benefits of it. |
125 |
|
126 |
Yes, it is a matter of opinion, and I feel GLEP 55 would do things in a |
127 |
very non-standard and confusing way, for users and for devs. |
128 |
|
129 |
The fact that it makes the technical solution particularly easy (or an |
130 |
easy short-cut) is not a justification. |
131 |
|
132 |
>> 3) Assuming going this route is a mistake, it could be hard to reverse. |
133 |
> |
134 |
> Not really. The entire point of this scheme is that we can change at any |
135 |
> time w/o breaking stuff. If we decide to go with .pbuild files for the |
136 |
> future, we can just do that. Old package managers still won't care. |
137 |
|
138 |
Along those lines, as I've said before, migrating to a new extension, |
139 |
*one-time*, as a solution to this, although not optimal, would be far |
140 |
more satisfactory than introducing a series of ever-changing extensions. |
141 |
|
142 |
For example, |
143 |
http://en.wikipedia.org/wiki/Alphabetical_list_of_file_extensions#E does |
144 |
not list ".eb", so gentoo could adopt that one, slowly phasing out |
145 |
".ebuild" over time. At least this would signify that it is an ".eb" |
146 |
(ebuild) file, not that it is an ".ebuild-4", which happens to be a type |
147 |
of ebuild file that requires version 4 of EAPI. |
148 |
|
149 |
-Joe |
150 |
-- |
151 |
gentoo-dev@l.g.o mailing list |