Re: [gentoo-portage-dev] PATCH: initial EAPI awareness

[Zac Medico]

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@g.o mailing list