1 |
Ciaran McCreesh wrote: |
2 |
> On Mon, 09 Jun 2008 20:15:56 -0600 |
3 |
> Joe Peterson <lavajoe@g.o> wrote: |
4 |
>> Yes, if everyone is perfect and remembers to do things perfectly |
5 |
>> right, there would never be issues in many things, but when you make |
6 |
>> something more complicated, there will be more errors. |
7 |
> |
8 |
> So we shouldn't ever change anything? |
9 |
|
10 |
Of course I don't mean that. But humans and computers are each good at |
11 |
a complementary set of things. Computers handle obscure complexity |
12 |
easily; humans do not, so it's better to let computers make our lives |
13 |
easier rather than the reverse when designing systems. |
14 |
|
15 |
>> So why would not a one-time new extension (e.g. ".eb") do the trick, |
16 |
>> just like ".cc" works for C programs? Unless you are talking about |
17 |
>> needing to specify the EAPI in the file if the more advanced features |
18 |
>> are to be used, but I see nothing wrong with that requirement - it's |
19 |
>> not much different than specifying a slot, keywords, whatever. |
20 |
> |
21 |
> Because then we won't be able to change source compatibility again in |
22 |
> the future without introducing yet another new extension. |
23 |
|
24 |
But GLEP 55 is suggesting exactly that: yet another extension for each |
25 |
new EAPI (I know it is defines this as ".ebuild-<EAPI>", but that is |
26 |
just semantics). |
27 |
|
28 |
Source compatibility is not an issue once the EAPI syntax in the file is |
29 |
defined and the package manager starts to recognize it. At that point |
30 |
it can handle the ebuild at whatever EAPI the ebuild declares. It is |
31 |
only the older unaware version of the package manager that would get |
32 |
confused, but that would be solved by a one-time extension change: the |
33 |
old one would not even look for the new (e.g.) ".eb" extension (only the |
34 |
old ".ebuild" one), which is exactly what GLEP 55 tries to address. But |
35 |
the extension change is only needed once. Once the EAPI syntax is |
36 |
introduced and the package manager has code to read it, the package |
37 |
manager is able to determine the EAPI for all future EAPIs. If some new |
38 |
syntax in an as-yet unsupported EAPI exists, the EAPI-version-aware |
39 |
package manager will not trip on it, since it can just not bother to |
40 |
deal with "future" EAPI ebuilds. |
41 |
|
42 |
Now, even if there is no extension change, if we wait long enough, the |
43 |
chances of an old machine stubbornly staying at an old (pre-EAPI-aware) |
44 |
portage version gets slimmer and slimmer. So I'm not even sure this |
45 |
one-time extension change is really mandatory. But if it is determined |
46 |
to be so, I still don't see why we need endless extension changes as |
47 |
suggested in GLEP 55. |
48 |
|
49 |
> Because the package manager doesn't know how to extract the EAPI from |
50 |
> ebuilds whose EAPI it doesn't support. For example, an EAPI 2 ebuild |
51 |
> might look like this: |
52 |
> |
53 |
> require mypackage using ANIMAL="monkey" |
54 |
> |
55 |
> How do current package managers understand that the EAPI there is 2? |
56 |
|
57 |
The old (non-aware) package manager version would not, and yes, it would |
58 |
fail. So there are two alternatives: wait long enough or do a one-time |
59 |
extension change. In the latter case, the package manager would not |
60 |
even see the new files. But the new package manager versions would |
61 |
determine the EAPI from a defined syntax and ignore ebuilds with |
62 |
"future" EAPIs. |
63 |
|
64 |
And I do understand the issue of sourcing, since ebuilds are bash. If |
65 |
sourcing is an issue (and I'm not sure it is an overriding one - that's |
66 |
a good discussion), I would suggest an out-of-band EAPI specifier, but |
67 |
not in the filename. Put it in a comment line in the header, like: |
68 |
|
69 |
# Copyright 1999-2008 Gentoo Foundation |
70 |
# Distributed under the terms of the GNU General Public License v2 |
71 |
# $Header: /var/cvsroot/gentoo-x86/sys-fs/btrfs-...$ |
72 |
# EAPI=2 |
73 |
|
74 |
inherit eutils |
75 |
... |
76 |
|
77 |
So, the first non-blank and non-'#' line (in this case, "inherit ...") |
78 |
would signify the end of the search for the EAPI= string, making parsing |
79 |
trivial. Therefore, the only rule would have to be that "EAPI=" needs |
80 |
to be in a header comment. Other rules could be that it needs to be the |
81 |
only thing on such a header line - whatever. |
82 |
|
83 |
Again, these are technical details, and I think we can all put our heads |
84 |
together to come up with the best way to do it. |
85 |
|
86 |
If sourcing is a better way to go (i.e. to allow EAPI= to be anywhere in |
87 |
the file with no comment char), caching it might be the answer. How to |
88 |
make this efficient would become an implementation detail. |
89 |
|
90 |
>>>> But what users *really* don't care about is EAPIs, and this GLEP |
91 |
>>>> would expose that technical detail to them in a very blatent way. |
92 |
>>> Anyone who cares about ebuilds at a file level has to care about |
93 |
>>> EAPIs. |
94 |
>> Not really. A typical user does not need to know about EAPIs at all, |
95 |
>> but he might want to peruse the portage tree to look for ebuilds. He |
96 |
>> might also want to grep for KEYWORDS or whatever. The user can delve |
97 |
>> into it as much as needed or desired, but if there are these |
98 |
>> mysterious EAPI numbers tacked onto the extensions, then it's an |
99 |
>> added complication that is not important to all users. |
100 |
> |
101 |
> The typical user should be using a tool to query that sort of thing. |
102 |
|
103 |
Sure, but my point is: some users *will* want to explore - why not |
104 |
encourage this? And if so, why not make the conventions used as clean |
105 |
and understandable (and elegant) as possible without added noise from |
106 |
details that do not belong at that (e.g. the filename) level? |
107 |
|
108 |
Gentoo is a technical distro, and we encourage users to get technical in |
109 |
every other way. Saying that they should remain at the portage |
110 |
interface level is not consistent with that philosophy. |
111 |
|
112 |
>> I assume you mean that EAPI needs to be in the file - again, is this |
113 |
>> bad? Many file formats specify a file format version as part of the |
114 |
>> file. |
115 |
> |
116 |
> It's a pain in the ass, because it means no introducing new global |
117 |
> scope functions and no changing behaviour of existing global scope |
118 |
> functions. |
119 |
> |
120 |
> Most file formats don't have to deal with the compatibility issues that |
121 |
> we do. For example, try feeding this C++ program to a C++0x compiler... |
122 |
|
123 |
Right: there are two things to consider: 1) do we want EAPI= to be in |
124 |
the global bash scope or out of band?, and 2) what happens when the |
125 |
syntax has errors? |
126 |
|
127 |
#1 needs more discussion, and #2, yes, should throw an error if invalid, |
128 |
but this also will be caught when the dev tests his/her ebuild (and/or |
129 |
by repoman), just as it is today, so I don't see a problem there. If it |
130 |
is an EAPI mismatch that would cause the syntax error, the updated |
131 |
package manager versions would handle it. |
132 |
|
133 |
-Joe |
134 |
|
135 |
-- |
136 |
gentoo-dev@l.g.o mailing list |