1 |
Ciaran McCreesh wrote: |
2 |
> On Mon, 09 Jun 2008 19:49:08 -0600 |
3 |
> Joe Peterson <lavajoe@g.o> wrote: |
4 |
>> I'm not saying it's a lot harder. But it is more complex and less |
5 |
>> elegant. Also, it is error-prone. If someone, by habit, looks for |
6 |
>> all "*.ebuild", he will miss a portion of the ebuilds and not even |
7 |
>> realize it at first (or ever). |
8 |
> |
9 |
> Yes, if something changes, and people carry on doing the old thing by |
10 |
> habit, then things go wrong. |
11 |
|
12 |
Yes, if everyone is perfect and remembers to do things perfectly right, |
13 |
there would never be issues in many things, but when you make something |
14 |
more complicated, there will be more errors. |
15 |
|
16 |
>> Well, in general, if you rely on extensions changing every time a |
17 |
>> program cannot deal with a new feature of a file format, it would be |
18 |
>> quite crazy. For example, if C programs had to start using ".c-2", |
19 |
>> ".c-3", etc., it would get ugly fast. |
20 |
> |
21 |
> Which is why programs that use any major C feature introduced since |
22 |
> 1980 use the extension '.cc' or '.cpp'. |
23 |
|
24 |
So why would not a one-time new extension (e.g. ".eb") do the trick, |
25 |
just like ".cc" works for C programs? Unless you are talking about |
26 |
needing to specify the EAPI in the file if the more advanced features |
27 |
are to be used, but I see nothing wrong with that requirement - it's not |
28 |
much different than specifying a slot, keywords, whatever. |
29 |
|
30 |
>> Also, it is easy to build EAPI checking into portage now, and when |
31 |
>> the requisite time passes, you only need to deal with situations |
32 |
>> where *very* old portage versions are still in use. Since portage is |
33 |
>> typically the first thing the system upgrades after a sync, I don't |
34 |
>> see a big issue. Or, if that is not acceptable, see my comment at |
35 |
>> the end about a one-time change to a new extension like ".eb". |
36 |
> |
37 |
> You completely miss the point of the GLEP. We need new extensions |
38 |
> precisely because current package managers can't handle future EAPIs |
39 |
> cleanly, and we need to carry on using new extensions because otherwise |
40 |
> we restrict what future EAPIs can do. |
41 |
|
42 |
No, I get that. But once you develop the concept of an EAPI, the very |
43 |
next package manager version can be aware of it and check the EAPI of an |
44 |
ebuild. If the ebuild specifies none, then it is old-style. If it |
45 |
specifies one that is unknown or newer than what that package manager |
46 |
version knows it can handle, it can handle that case (ignore it or |
47 |
whatever). I don't see why you need to keep bumping the |
48 |
filename/extension every time it changes from that point forward. |
49 |
|
50 |
>> But what users *really* don't care about is EAPIs, and this GLEP would |
51 |
>> expose that technical detail to them in a very blatent way. |
52 |
> |
53 |
> Anyone who cares about ebuilds at a file level has to care about EAPIs. |
54 |
|
55 |
Not really. A typical user does not need to know about EAPIs at all, |
56 |
but he might want to peruse the portage tree to look for ebuilds. He |
57 |
might also want to grep for KEYWORDS or whatever. The user can delve |
58 |
into it as much as needed or desired, but if there are these mysterious |
59 |
EAPI numbers tacked onto the extensions, then it's an added complication |
60 |
that is not important to all users. |
61 |
|
62 |
>> Along those lines, as I've said before, migrating to a new extension, |
63 |
>> *one-time*, as a solution to this, although not optimal, would be far |
64 |
>> more satisfactory than introducing a series of ever-changing |
65 |
>> extensions. |
66 |
> |
67 |
> No it won't. It means future EAPIs will be restricted to some |
68 |
> particular source format. |
69 |
|
70 |
I assume you mean that EAPI needs to be in the file - again, is this |
71 |
bad? Many file formats specify a file format version as part of the file. |
72 |
|
73 |
-Joe |
74 |
|
75 |
-- |
76 |
gentoo-dev@l.g.o mailing list |