On Tue, 24 Feb 2009 15:17:01 -0500 Richard Freeman <ri...@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
signature.asc
Description: PGP signature
