Ciaran McCreesh wrote:
> On Tue, 24 Feb 2009 15:17:01 -0500
> Richard Freeman <rich0@g.o> wrote:
>> Why?  Just parse the EAPI out of the file before you interpret the 
>> version and name from the filename.  Indeed - you could have a future 
>> EAPI remove the name and version from the filename entirely.  If a 
>> package manager doesn't understand the EAPI in a file it shouldn't do 
>> anything at all with it.
> 
> Then you get into the mess of deciding what is or is not an ebuild...
> Currently it's well defined; if you start making the package manager
> look inside files things get very confusing...

an ebuild is something ending with .ebuild ...

> It means opening a file that would otherwise not be opened at all. And
> if the EAPI is in the file, you have to fish inside that file to pull
> it out before you can work out whether the cache entry that might
> contain the EAPI already is valid.

Keeping in mind that:
- if the cache is present you won't do it (so normal users aren't touched)
- you just need a way to upgrade portage and nothing else.

You:
- have to open them on regen, no matter what (you are adding it to portage)
- the cache entry has already the eapi value so there it is.

>>> ..and it means we can't make arbitrary format changes.
>> Well, you would need to preserve the EAPI in the header, but other
>> than that you could actually turn an ebuild into an otherwise
>> completely binary file, or whatever.  Just how much more flexibility
>> than that is needed?
> 
> I remember hearing that years ago, except it was "well you can't change
> global scope behaviour for EAPIs, but just how much more flexibility
> than that is needed?".

Given that the fixed header gives you ALL the flexibility. You may give 
provision to consider the next bytes as any kind of serialization...

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero