Luca Barbato wrote: > Tiziano Müller wrote: >> 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. >> > > Check if exists a line EAPI=*$, if does and the rest of the string > matches an understood eapi, go on sourcing, otherwise ignore/mask it...
... and package managers which don't do that already still fail. -- [email protected] mailing list
