1 |
On Mon, 09 Jun 2008 21:36:24 -0600 |
2 |
Joe Peterson <lavajoe@g.o> wrote: |
3 |
> Of course I don't mean that. But humans and computers are each good |
4 |
> at a complementary set of things. Computers handle obscure complexity |
5 |
> easily; humans do not, so it's better to let computers make our lives |
6 |
> easier rather than the reverse when designing systems. |
7 |
|
8 |
And a file extension is far less obscurely complex than enforcing |
9 |
arbitrary syntax restrictions upon ebuilds. |
10 |
|
11 |
|
12 |
> >> So why would not a one-time new extension (e.g. ".eb") do the |
13 |
> >> trick, just like ".cc" works for C programs? Unless you are |
14 |
> >> talking about needing to specify the EAPI in the file if the more |
15 |
> >> advanced features are to be used, but I see nothing wrong with |
16 |
> >> that requirement - it's not much different than specifying a slot, |
17 |
> >> keywords, whatever. |
18 |
> > |
19 |
> > Because then we won't be able to change source compatibility again |
20 |
> > in the future without introducing yet another new extension. |
21 |
> |
22 |
> But GLEP 55 is suggesting exactly that: yet another extension for each |
23 |
> new EAPI (I know it is defines this as ".ebuild-<EAPI>", but that is |
24 |
> just semantics). |
25 |
|
26 |
GLEP 55 suggests a backwards compatible, forwards compatible way of |
27 |
dealing with the problem that doesn't involve adding new sets of rules |
28 |
every few EAPIs. |
29 |
|
30 |
> Source compatibility is not an issue once the EAPI syntax in the file |
31 |
> is defined and the package manager starts to recognize it. At that |
32 |
> point it can handle the ebuild at whatever EAPI the ebuild declares. |
33 |
|
34 |
No it can't. EAPI has to be known before the source can start. Bash |
35 |
doesn't provide traps for executing code upon changed variables. |
36 |
|
37 |
> It is only the older unaware version of the package manager that |
38 |
> would get confused, but that would be solved by a one-time extension |
39 |
> change: the old one would not even look for the new (e.g.) ".eb" |
40 |
> extension (only the old ".ebuild" one), which is exactly what GLEP 55 |
41 |
> tries to address. But the extension change is only needed once. |
42 |
|
43 |
No, it's only needed once per non-trivial change. So we might as well |
44 |
just change it for every EAPI. |
45 |
|
46 |
> Once the EAPI syntax is introduced and the package manager has code |
47 |
> to read it, the package manager is able to determine the EAPI for all |
48 |
> future EAPIs. |
49 |
|
50 |
Which means we can't change anything useful in future EAPIs. Which, |
51 |
funnily enough, is what the GLEP is designed to solve. |
52 |
|
53 |
> Now, even if there is no extension change, if we wait long enough, the |
54 |
> chances of an old machine stubbornly staying at an old |
55 |
> (pre-EAPI-aware) portage version gets slimmer and slimmer. So I'm |
56 |
> not even sure this one-time extension change is really mandatory. |
57 |
|
58 |
Except it is, because current EAPI aware package managers still can't |
59 |
deal with global scope changes. |
60 |
|
61 |
> > Because the package manager doesn't know how to extract the EAPI |
62 |
> > from ebuilds whose EAPI it doesn't support. For example, an EAPI 2 |
63 |
> > ebuild might look like this: |
64 |
> > |
65 |
> > require mypackage using ANIMAL="monkey" |
66 |
> > |
67 |
> > How do current package managers understand that the EAPI there is 2? |
68 |
> |
69 |
> The old (non-aware) package manager version would not, and yes, it |
70 |
> would fail. So there are two alternatives: wait long enough or do a |
71 |
> one-time extension change. In the latter case, the package manager |
72 |
> would not even see the new files. But the new package manager |
73 |
> versions would determine the EAPI from a defined syntax and ignore |
74 |
> ebuilds with "future" EAPIs. |
75 |
|
76 |
And then how do we deal with EAPI 3, where the syntax changes again? |
77 |
|
78 |
> And I do understand the issue of sourcing, since ebuilds are bash. If |
79 |
> sourcing is an issue (and I'm not sure it is an overriding one - |
80 |
> that's a good discussion), I would suggest an out-of-band EAPI |
81 |
> specifier, but not in the filename. Put it in a comment line in the |
82 |
> header, like: |
83 |
> |
84 |
> # Copyright 1999-2008 Gentoo Foundation |
85 |
> # Distributed under the terms of the GNU General Public License v2 |
86 |
> # $Header: /var/cvsroot/gentoo-x86/sys-fs/btrfs-...$ |
87 |
> # EAPI=2 |
88 |
|
89 |
Which is way more obscure, complex and arbitrary than a file extension |
90 |
change. And it still imposes massive restrictions upon future EAPIs. |
91 |
|
92 |
> Again, these are technical details, and I think we can all put our |
93 |
> heads together to come up with the best way to do it. |
94 |
|
95 |
Every issue you've raised so far was already discussed and debunked the |
96 |
first time this discussion happened. Please read the original |
97 |
discussions before continuing. |
98 |
|
99 |
> > The typical user should be using a tool to query that sort of thing. |
100 |
> |
101 |
> Sure, but my point is: some users *will* want to explore - why not |
102 |
> encourage this? And if so, why not make the conventions used as clean |
103 |
> and understandable (and elegant) as possible without added noise from |
104 |
> details that do not belong at that (e.g. the filename) level? |
105 |
|
106 |
And when they do explore, they learn straight away what EAPI is. |
107 |
|
108 |
> Gentoo is a technical distro, and we encourage users to get technical |
109 |
> in every other way. Saying that they should remain at the portage |
110 |
> interface level is not consistent with that philosophy. |
111 |
|
112 |
And users who get technical knowing what EAPI is is a good thing. |
113 |
|
114 |
> Right: there are two things to consider: 1) do we want EAPI= to be in |
115 |
> the global bash scope or out of band?, and 2) what happens when the |
116 |
> syntax has errors? |
117 |
> |
118 |
> #1 needs more discussion |
119 |
|
120 |
We had that discussion when the GLEP was first proposed. |
121 |
|
122 |
-- |
123 |
Ciaran McCreesh |