1 |
Joe Peterson ha scritto: |
2 |
> It was mentioned that "comments are to be ignored", but you point out a |
3 |
> perfect and very fundamental example of where this is not true: |
4 |
> |
5 |
> #!/usr/bin/env bash |
6 |
> |
7 |
> Putting another line close to this one with: |
8 |
> |
9 |
> #EAPI=42 |
10 |
> |
11 |
> or |
12 |
> |
13 |
> #!EAPI=42 |
14 |
> |
15 |
> if you like (conforms more to the shell script specifier), is not too |
16 |
> muchh of a stretch. |
17 |
|
18 |
The so-called shebang; very good in my opinion! |
19 |
|
20 |
Works very well for true shell scripts. why it can't work for ebuilds? |
21 |
|
22 |
|
23 |
First, I think of two alternatives: |
24 |
|
25 |
1) the interpreter is the EAPI (with /usr/bin/ebuild being EAPI=0) |
26 |
this will be the first line of a EAPI=0 ebuild: |
27 |
|
28 |
#!/usr/bin/ebuild |
29 |
|
30 |
this will be a EAPI=paludis ebuild: |
31 |
|
32 |
#!/usr/bin/ebuild-paludis |
33 |
|
34 |
apparently it's the same mechanism the shell uses to execute a shell |
35 |
script, except for the fact that: |
36 |
* ebuild is not an executable file |
37 |
* an external program is used to determine the EAPI (i.e.: extract the |
38 |
shebang) |
39 |
|
40 |
|
41 |
2) fixed interpreter name, use arguments for switching EAPIs |
42 |
|
43 |
this is another option, wich carries itself a GREAT power of leaving an |
44 |
open door when in the future will happen something similar to what we |
45 |
have now, where switching the EAPI (or replace EAPI with something else) |
46 |
is critical and breaks compatibility. |
47 |
|
48 |
example - EAPI=0: |
49 |
#!/usr/bin/ebuild |
50 |
... |
51 |
another eapi: |
52 |
#!/usr/bin/ebuild -eapi paludis |
53 |
|
54 |
This allows virtually unlimited cases similar to this; for example when |
55 |
switching to <another-feature-that-breaks-things>, another switch will |
56 |
be used: |
57 |
|
58 |
#!/usr/bin/ebuild -eapi foo -fluffy bar |
59 |
|
60 |
|
61 |
|
62 |
Advantages of both solutions: |
63 |
* easy to parse |
64 |
* doesn't break compatibility |
65 |
|
66 |
What it does not address: |
67 |
* doesn't break compatibility |
68 |
|
69 |
In fact, it should break compatibility. |
70 |
again I can think of two solutions: |
71 |
1) change the ebuild extension to a different value, once and |
72 |
(hopefully) forever, e.g. from .ebuild to .xbuild, and leave the minimal |
73 |
set of .ebuild-s for the upgrade path |
74 |
2) use two repositories: the legacy one, needed for the upgrade path, |
75 |
and the shyny-new-repository with the new ebuilds format |
76 |
|
77 |
|
78 |
best regards, |
79 |
Federico Ferri |
80 |
|
81 |
-- |
82 |
#include <stdio.h> |
83 |
main(){printf("%x",4275974592);} |
84 |
|
85 |
|
86 |
-----BEGIN GEEK CODE BLOCK----- |
87 |
Version: 3.12 |
88 |
GCS d-(--) a- C++$ UL+++$ L+++$ E--- W++@ w--@ |
89 |
PE PGP+ R- tv-- DI++>+++ D++ h+ |
90 |
------END GEEK CODE BLOCK------ |