1 |
On Mon, 09 Jun 2008 20:15:56 -0600 |
2 |
Joe Peterson <lavajoe@g.o> wrote: |
3 |
> Yes, if everyone is perfect and remembers to do things perfectly |
4 |
> right, there would never be issues in many things, but when you make |
5 |
> something more complicated, there will be more errors. |
6 |
|
7 |
So we shouldn't ever change anything? |
8 |
|
9 |
> > Which is why programs that use any major C feature introduced since |
10 |
> > 1980 use the extension '.cc' or '.cpp'. |
11 |
> |
12 |
> So why would not a one-time new extension (e.g. ".eb") do the trick, |
13 |
> just like ".cc" works for C programs? Unless you are talking about |
14 |
> needing to specify the EAPI in the file if the more advanced features |
15 |
> are to be used, but I see nothing wrong with that requirement - it's |
16 |
> not much different than specifying a slot, keywords, whatever. |
17 |
|
18 |
Because then we won't be able to change source compatibility again in |
19 |
the future without introducing yet another new extension. |
20 |
|
21 |
> > You completely miss the point of the GLEP. We need new extensions |
22 |
> > precisely because current package managers can't handle future EAPIs |
23 |
> > cleanly, and we need to carry on using new extensions because |
24 |
> > otherwise we restrict what future EAPIs can do. |
25 |
> |
26 |
> No, I get that. But once you develop the concept of an EAPI, the very |
27 |
> next package manager version can be aware of it and check the EAPI of |
28 |
> an ebuild. If the ebuild specifies none, then it is old-style. If it |
29 |
> specifies one that is unknown or newer than what that package manager |
30 |
> version knows it can handle, it can handle that case (ignore it or |
31 |
> whatever). I don't see why you need to keep bumping the |
32 |
> filename/extension every time it changes from that point forward. |
33 |
|
34 |
Because the package manager doesn't know how to extract the EAPI from |
35 |
ebuilds whose EAPI it doesn't support. For example, an EAPI 2 ebuild |
36 |
might look like this: |
37 |
|
38 |
require mypackage using ANIMAL="monkey" |
39 |
|
40 |
How do current package managers understand that the EAPI there is 2? |
41 |
|
42 |
> >> But what users *really* don't care about is EAPIs, and this GLEP |
43 |
> >> would expose that technical detail to them in a very blatent way. |
44 |
> > |
45 |
> > Anyone who cares about ebuilds at a file level has to care about |
46 |
> > EAPIs. |
47 |
> |
48 |
> Not really. A typical user does not need to know about EAPIs at all, |
49 |
> but he might want to peruse the portage tree to look for ebuilds. He |
50 |
> might also want to grep for KEYWORDS or whatever. The user can delve |
51 |
> into it as much as needed or desired, but if there are these |
52 |
> mysterious EAPI numbers tacked onto the extensions, then it's an |
53 |
> added complication that is not important to all users. |
54 |
|
55 |
The typical user should be using a tool to query that sort of thing. |
56 |
|
57 |
> >> Along those lines, as I've said before, migrating to a new |
58 |
> >> extension, *one-time*, as a solution to this, although not |
59 |
> >> optimal, would be far more satisfactory than introducing a series |
60 |
> >> of ever-changing extensions. |
61 |
> > |
62 |
> > No it won't. It means future EAPIs will be restricted to some |
63 |
> > particular source format. |
64 |
> |
65 |
> I assume you mean that EAPI needs to be in the file - again, is this |
66 |
> bad? Many file formats specify a file format version as part of the |
67 |
> file. |
68 |
|
69 |
It's a pain in the ass, because it means no introducing new global |
70 |
scope functions and no changing behaviour of existing global scope |
71 |
functions. |
72 |
|
73 |
Most file formats don't have to deal with the compatibility issues that |
74 |
we do. For example, try feeding this C++ program to a C++0x compiler: |
75 |
|
76 |
void foo(int x) |
77 |
{ |
78 |
auto bool requires(x == 1); |
79 |
} |
80 |
|
81 |
Or this C++0x program to a C++ compiler: |
82 |
|
83 |
template <std::Regular T_> |
84 |
T__ && foo(T_ x) |
85 |
{ |
86 |
std::list<std::list<T_>> l; |
87 |
return x; |
88 |
} |
89 |
|
90 |
In both cases, you get user visible messy errors. That's not something |
91 |
we have the luxury of being able to do. |
92 |
|
93 |
-- |
94 |
Ciaran McCreesh |