[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] A new glep: Ebuild format and metadata handling
From:       Richard Freeman <rich0 () gentoo ! org>
Date:       2009-05-31 22:09:11
Message-ID: 4A230007.9090708 () gentoo ! org
[Download RAW message or body]

Patrick Lauer wrote:
> If I should have forgotten any approach or misrepresented one I'd
> appreciate an updated or rephrased section so it can be easily
> updated.
> 

This keeps coming up for some reason:

parsers: It enforces some minor limitations, for example EAPI needs to 
be unique and cannot be overridden by eclasses.

I agree with this sentence.  However, the exact same limitation applies 
to GLEP55 and it isn't mentioned there.  So, that paragraph should read:

glep55: See GLEP55. To summarize: The eapi is put into the file name so 
that the package manager knows the EAPI (and thus how to handle this 
file format). While it simplifies the eapi discovery this comes at a 
high price as there is no reliable way to find and validate all ebuilds. 
  It also enforces some minor limitations, for example EAPI needs to be 
unique and cannot be overridden by eclasses. Some people also see it as 
bad design as it exposes file internals in the filename.

Likwise, the pro/con list for glep55 should include the line:
   (+-) enforces some restriction on the possible changes in future EAPIs

In this particular regard the parser and the glep55 approach have the 
exact same limitations.

Now, an alternative to glep55 that has two different EAPI-like values 
(one for the initial file parsing and one for actually performing the 
build) might lose this limitation.  However, this is not the case with 
glep55 as it is presently stated.


[prev in list] [next in list] [prev in thread] [next in thread]