1 |
Santiago M. Mola wrote: |
2 |
> On Tue, Jun 10, 2008 at 10:20 PM, Federico Ferri <xaero@××××××.it> wrote: |
3 |
>> The so-called shebang; very good in my opinion! |
4 |
>> |
5 |
>> Works very well for true shell scripts. why it can't work for ebuilds? |
6 |
> |
7 |
> This option was already discussed when GLEP 55 was proposed, and in my |
8 |
> opinion it's totally discarded. The concept of shebang doesn't apply |
9 |
> here at all. Plus /usr/bin/ebuild is a binary provided by portage |
10 |
> which has nothing to do with the process of sourcing ebuilds nor even |
11 |
> with the internals of portage (not to speak of other package |
12 |
> managers). |
13 |
> |
14 |
|
15 |
I had thought of this option as well - I agree that it has a lot of |
16 |
issues. I agree that ebuild wouldn't be the right tool, but in the |
17 |
right framework I could see how something like this might work. |
18 |
|
19 |
Here is how a portage tree might be handled by a future package manager |
20 |
that uses shebangs to implement any number of EAPIs that have almost no |
21 |
restrictions on file contents other than the shebang: |
22 |
|
23 |
When new "ebuilds" are synced into the repository, they are executed. |
24 |
If the interpreter doesn't exist, then it is an unsupported EAPI and the |
25 |
failure is silently ignored (or logged or whatever). If the interpreter |
26 |
does exist it will interpret the file properly - perhaps using a EAPI |
27 |
command-line option from the shebang line or whatever is appropriate for |
28 |
that EAPI which the interpreter obviously understands. If the |
29 |
interpreter determines that the file uses an EAPI it doesn't know, it |
30 |
aborts execution and skips the package. That makes the scheme always |
31 |
backwards compatible (well, at least until the switch to this approach - |
32 |
current package managers wouldn't be compatible). |
33 |
|
34 |
When the new ebuild is executed, it will call appropriate functions to |
35 |
register itself into the local repository. That registration might |
36 |
include callbacks of some kind or whatever - the whole way the ebuild |
37 |
works could vary by EAPI - since the interpreter used by the EAPI could |
38 |
change. The only restriction for compatibility is a standard shebang |
39 |
line. |
40 |
|
41 |
Each ebuild would only be executed upon a change when it is synced, so |
42 |
the overhead isn't huge. At that point all the data is stored in a |
43 |
local cache and the ebuilds themselves don't get touched until they are |
44 |
installed. Installation will work in an EAPI-dependent way - perhaps by |
45 |
executing the ebuild with a particular parameter or environment setting |
46 |
or whatever. The package manager will know since it has already been |
47 |
established that this is a supported EAPI by the fact that the ebuild |
48 |
got processed when it was synced in. |
49 |
|
50 |
This kind of system also makes it easy to support some scenarios that |
51 |
are currently hard: |
52 |
|
53 |
1. Download a random ebuild off the internet and want to add it to your |
54 |
repository? Rather than having to put it in a local portage tree you |
55 |
could just execute it from anywhere and it would register itself in its |
56 |
present location - and act like any other package in the tree. |
57 |
|
58 |
2. No need for utilities like ebuild to manipulate the install process |
59 |
- instead just execute the ebuild with the appropriate parameters or |
60 |
whatever to get it to do the install process. |
61 |
|
62 |
On the other hand, this is a big change from the present, and I'm not |
63 |
convinced that it will actually be a big improvement over some of the |
64 |
other EAPI ideas being floated around. However, it is a |
65 |
potentially-neat idea... |
66 |
|
67 |
-- |
68 |
gentoo-dev@l.g.o mailing list |