Note: Due to technical difficulties, the Archives are currently not up to date.
GMANE provides an alternative service for most mailing lists. c.f. bug 424647
List Archive: gentoo-dev
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...
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@g.o mailing list
|
|