Marius Mauch wrote:
On 08/30/05 Paul de Vrieze wrote:
I don't think it is a wise path to interpret EAPI's as integers at
all. There should not be guarantees of forward or backward
compatibility between versions. Interpreting them as integers seems
to imply that. Basically I think that EAPI could be anything wanted,
similar to SLOTS. Of course using digits is easy for humans.
I've to agree with Paul here, portage should hold a list of all EAPI
values it understands, not a maximum value.
I also agree. It seems like a list of string identifiers will give us a high
level of forward flexibility.
For the implementation we can have a chain of EAPI handlers that are capable of
determining whether or not they support a given EAPI. The first handler in the
chain to accept the package will be allowed to handle it. Internally, these
handlers may be able to share libraries and/or inherit from eachother.
Brian Harring wrote:
Either way, getting to the point of why strings suck badly in the
point where it matters- as format version identifiers for the code
that does the actual work.
Example code for numeric, say we have eapi 0-5 at this point.
def configure(self):
if self.pkg.eapi > 0:
...call configure phase...
return
example code for strings
def configure(self):
if self.pkg.eapi in ("0", "1", "2", "3", "4", "5"):
...call configure phase...
return
This sucks.
Yes, the above seems bad. That is why I have suggested that a chain of
handlers be used. Select the first handler in the chain that recognizes the
ebuild's eapi. The selected handler would not need the above conditionals
because it would be designed specifically for the eapi that it handles.
[snip]
capabilities = {"0":["configure"],
"1":["configure", "test_src_uri"],
"2":["configure", "test_src_uri"],
"3":["configure", "test_src_uri", "full_depriving"],
"4":["configure", "test_src_uri", "full_depriving",
"user_management"],
"5":["configure", "test_src_uri", "full_depriving",
"user_management"],}
def configure(self):
if "configure" in capabilities.get(eapi, []):
...call configure phase...
return
Where appropriate, handlers could inherit from eachother or use shared
libraries in order to provide the above capabilities.
[snip]
That said, if you dig through my earlier patch, and comments about
needing to handle int conversion better rather then flattening it to
0, the code *is* forwards compatible if someone decides to stick strings
into EAPI. In other words, it's a moot debate due to the fact that
the internal representation of eapi (is it a string, or is it an int?)
is specific to that portage version; whatever version supports an eapi
with strings tagged into has the fun of addressing the issues I've
brought up above.
Okay, if it works and it's forward compatible with string lists, then I'm happy
with it. :)
Zac
--
gentoo-portage-dev@gentoo.org mailing list
