Joe Peterson wrote: > Ciaran McCreesh wrote: >> And a file extension is far less obscurely complex than enforcing >> arbitrary syntax restrictions upon ebuilds. > > I disagree. One is exposed to devs only as ebuild syntax; the other is > exposed in an inappropriate location to everyone looking at the portage > tree. > >> No it can't. EAPI has to be known before the source can start. Bash >> doesn't provide traps for executing code upon changed variables. > > Doing it out-of-band solve this. > >> No, it's only needed once per non-trivial change. So we might as well >> just change it for every EAPI. > > Huh? If the "new" portage knows how to determine the EAPI definitively > (and that would be defined), it can deal with the differences. > >> And then how do we deal with EAPI 3, where the syntax changes again? > > Portage (or whatever PM) reads the EAPI, determines it is 3, and goes > from there. If you change the way you declare EAPI each time, yeah, > that's a problem, but I'm not sure why that would ne necessary. No, that is not the problem.
Example: In EAPI 42 we define that the package manager must provide a global function extract_depend_from_setup_py() such that it is callable at a global level in an ebuild like this *snip start* # Copyright 1999-2007 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ EAPI=42 DESCRIPTION="A library aiming to support agile and test-driven python development on various levels." SRC_URI="http://codespeak.net/download/${PN}/${P}.tar.gz"; HOMEPAGE="http://codespeak.net/py/"; KEYWORDS="~amd64 ~x86" SLOT="0" LICENSE="MIT" IUSE="" extract_depend_from_setup_py *snip end* Now, a package manager (or a tool) not knowing EAPI 42 will fail when it tries to source the above ebuild to determine the EAPI version (as it is being currently done as far as I understood it) because extract_depend_from_setup_py is undefined. So it won't even be able to read out the EAPI. With the EAPI in the filename tools now knowing EAPI-42 will either ignore the above foo-1.0.ebuild-42 or mask it because they may identify the EAPI-version without sourcing the ebuild. And: No, just sourcing the ebuild and simply masking it because we can't source it is a no-go (since you're abusing error-handling as a case switch). -- gentoo-dev@lists.gentoo.org mailing list
