1 |
Ciaran McCreesh wrote: |
2 |
> On Tue, 24 Feb 2009 15:17:01 -0500 |
3 |
> Richard Freeman <rich0@g.o> wrote: |
4 |
>> Why? Just parse the EAPI out of the file before you interpret the |
5 |
>> version and name from the filename. Indeed - you could have a future |
6 |
>> EAPI remove the name and version from the filename entirely. If a |
7 |
>> package manager doesn't understand the EAPI in a file it shouldn't do |
8 |
>> anything at all with it. |
9 |
> |
10 |
> Then you get into the mess of deciding what is or is not an ebuild... |
11 |
> Currently it's well defined; if you start making the package manager |
12 |
> look inside files things get very confusing... |
13 |
|
14 |
an ebuild is something ending with .ebuild ... |
15 |
|
16 |
> It means opening a file that would otherwise not be opened at all. And |
17 |
> if the EAPI is in the file, you have to fish inside that file to pull |
18 |
> it out before you can work out whether the cache entry that might |
19 |
> contain the EAPI already is valid. |
20 |
|
21 |
Keeping in mind that: |
22 |
- if the cache is present you won't do it (so normal users aren't touched) |
23 |
- you just need a way to upgrade portage and nothing else. |
24 |
|
25 |
You: |
26 |
- have to open them on regen, no matter what (you are adding it to portage) |
27 |
- the cache entry has already the eapi value so there it is. |
28 |
|
29 |
>>> ..and it means we can't make arbitrary format changes. |
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 |
Given that the fixed header gives you ALL the flexibility. You may give |
40 |
provision to consider the next bytes as any kind of serialization... |
41 |
|
42 |
lu |
43 |
|
44 |
-- |
45 |
|
46 |
Luca Barbato |
47 |
Gentoo Council Member |
48 |
Gentoo/linux Gentoo/PPC |
49 |
http://dev.gentoo.org/~lu_zero |