1 |
On Tue, 24 Feb 2009 15:17:01 -0500 |
2 |
Richard Freeman <rich0@g.o> wrote: |
3 |
> Why? Just parse the EAPI out of the file before you interpret the |
4 |
> version and name from the filename. Indeed - you could have a future |
5 |
> EAPI remove the name and version from the filename entirely. If a |
6 |
> package manager doesn't understand the EAPI in a file it shouldn't do |
7 |
> anything at all with it. |
8 |
|
9 |
Then you get into the mess of deciding what is or is not an ebuild... |
10 |
Currently it's well defined; if you start making the package manager |
11 |
look inside files things get very confusing... |
12 |
|
13 |
> > ..and it means over doubling the best possible time to work out a |
14 |
> > dependency tree in the common case where the metadata cache is |
15 |
> > valid. |
16 |
> |
17 |
> I can see why it takes an extra pass - but does that mean a doubling |
18 |
> of time? Couldn't the EAPI be cached as well to reduce disk access? |
19 |
|
20 |
It means opening a file that would otherwise not be opened at all. And |
21 |
if the EAPI is in the file, you have to fish inside that file to pull |
22 |
it out before you can work out whether the cache entry that might |
23 |
contain the EAPI already is valid. |
24 |
|
25 |
(We don't have to do this currently because inherit hasn't changed |
26 |
behaviour at all.) |
27 |
|
28 |
> > ..and it means we can't make arbitrary format changes. |
29 |
> |
30 |
> Well, you would need to preserve the EAPI in the header, but other |
31 |
> than that you could actually turn an ebuild into an otherwise |
32 |
> completely binary file, or whatever. Just how much more flexibility |
33 |
> than that is needed? |
34 |
|
35 |
I remember hearing that years ago, except it was "well you can't change |
36 |
global scope behaviour for EAPIs, but just how much more flexibility |
37 |
than that is needed?". |
38 |
|
39 |
-- |
40 |
Ciaran McCreesh |