Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]

On Tue, 24 Feb 2009 15:17:01 -0500
Richard Freeman <rich0@gentoo.org> 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...

> > ..and it means over doubling the best possible time to work out a
> > dependency tree in the common case where the metadata cache is
> > valid.
> 
> I can see why it takes an extra pass - but does that mean a doubling
> of time?  Couldn't the EAPI be cached as well to reduce disk access?

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.

(We don't have to do this currently because inherit hasn't changed
behaviour at all.)

> > ..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?".

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]