On Wednesday 15 February 2006 16:48, Alec Warner wrote: > Paul de Vrieze wrote: > > On Tuesday 14 February 2006 13:44, Alec Warner wrote: > >>Well that problem would be, no one wants to modify everything in > >>app-portage/ :). If my portage EAPI is 1, but my tools don't support > >>processing +- in IUSE, how does EAPI help me here? The support check > >>is only for portage_const, so the tool remains fucked. Unless I'm > >>missing something. > > > > Tools should also be EAPI aware. I know too many aren't, but that > > doesn't mean they shouldn't be. > > > > Paul > > I guess my point here is, last I checked we can't pass an EAPI less > than portage_const.EAPI.
EAPI is not sortable, as such a lower EAPI should have no meaning for anything. Portage supports a welldefined set of EAPI values. The fact that these are based on numbers is because humans like that, portage however needs just see whether that particular version is supported. The portage api should expose the EAPI version of an ebuild, and tools could then map this against their own set of supported EAPI versions. And perhaps also portage could have an api identifier that the tools could also check against. > > In this example, say portage's EAPI is at 2, but my tool only handles > EAPI 0, there is no way to set this in portage so I get EAPI 0 results. > So perhaps we need this implemented as well. The first thing would be to just refuse functioning on ebuilds with an unsupported EAPI version. Portage does not itself have an EAPI version. It has a list of supported ebuild EAPI values. Those would in that case be ["1", "2", "3"]. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net
pgp3OxGrjBcVr.pgp
Description: PGP signature
