[gentoo-dev] EAPI-2 and src_configure in eclasses

[gentoo-dev] EAPI-2 and src_configure in eclasses

[Ulrich Mueller]

How should exporting of src_configure in eclasses be handled? Should
it be conditional, depending on the EAPI? Or is it O.K. to export
src_configure unconditionally, since it doesn't harm for EAPI<2?

A concrete example is elisp.eclass which should export an empty
elisp_src_configure function for EAPI=2.

Ulrich

Re: [gentoo-dev] EAPI-2 and src_configure in eclasses

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

On Sun, 5 Oct 2008 15:36:30 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> How should exporting of src_configure in eclasses be handled? Should
> it be conditional, depending on the EAPI? Or is it O.K. to export
> src_configure unconditionally, since it doesn't harm for EAPI<2?

Export it if and only if EAPI is 2.

Note that this means EAPI really really has to be set as the first
thing in the ebuild (*cough* or in the file extension).

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 and src_configure in eclasses

[Alexis Ballier]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

On Sun, 5 Oct 2008 15:07:27 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sun, 5 Oct 2008 15:36:30 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
> > How should exporting of src_configure in eclasses be handled? Should
> > it be conditional, depending on the EAPI? Or is it O.K. to export
> > src_configure unconditionally, since it doesn't harm for EAPI<2?
> 
> Export it if and only if EAPI is 2.
> 
> Note that this means EAPI really really has to be set as the first
> thing in the ebuild (*cough* or in the file extension).

By the way, do we really want to special case eapi-2 in every eclass ?
That's lot of code duplication and will get even worse when we'll reach
eapi-42. That would have been cool to have a pm function that tells
"has my eapi foo support" but that sort of bites its tail that way.
An eapi.eclass with such functions and lists of eapi & features
maintained there could help though.
An EXPORT_FUNCTIONS ignoring any function its doesn't know for its eapi
would help too.

Alexis.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 and src_configure in eclasses

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

On Sun, 5 Oct 2008 16:15:46 +0200
Alexis Ballier <aballier@gentoo.org> wrote:
> An eapi.eclass with such functions and lists of eapi & features
> maintained there could help though.

The problem is, 'features' change between EAPIs. For example, all three
EAPIs have src_compile, but it does different things for all three. One
can't assume that a feature working for current EAPIs will carry on
working for future EAPIs, and even if it does there can be other
interactions that break.

> An EXPORT_FUNCTIONS ignoring any function its doesn't know for its
> eapi would help too.

An EXPORT_FUNCTIONS ignoring incorrect usage makes one less place
checking for eclass screwups...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 and src_configure in eclasses

[Alexis Ballier]

[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]

On Sun, 5 Oct 2008 15:24:20 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sun, 5 Oct 2008 16:15:46 +0200
> Alexis Ballier <aballier@gentoo.org> wrote:
> > An eapi.eclass with such functions and lists of eapi & features
> > maintained there could help though.
> 
> The problem is, 'features' change between EAPIs. For example, all
> three EAPIs have src_compile, but it does different things for all
> three. One can't assume that a feature working for current EAPIs will
> carry on working for future EAPIs, and even if it does there can be
> other interactions that break.

Indeed; different names could be given to different implementations of
the same thing, but that might completely kill the point of abstracting
it.
Maybe eclasses should die on unknown eapi; the fact is I really hate the
current way it's done when switching an ebuild to EAPI-2 which uses
an eclass that exports src_compile; most eclasses don't special case
eapi-2 yet and we end up running econf twice at best. I fear that'll be
the same with eapi-3, eapi-4, etc. (supposing that they'll support
src_configure too)

> > An EXPORT_FUNCTIONS ignoring any function its doesn't know for its
> > eapi would help too.
> 
> An EXPORT_FUNCTIONS ignoring incorrect usage makes one less place
> checking for eclass screwups...

yes; that's just a matter of choice though, but for eclasses it's
probably not luxury.


Alexis.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 and src_configure in eclasses

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]

On Sun, 5 Oct 2008 17:07:40 +0200
Alexis Ballier <aballier@gentoo.org> wrote:
> Maybe eclasses should die on unknown eapi; the fact is I really hate
> the current way it's done when switching an ebuild to EAPI-2 which
> uses an eclass that exports src_compile; most eclasses don't special
> case eapi-2 yet and we end up running econf twice at best. I fear
> that'll be the same with eapi-3, eapi-4, etc. (supposing that they'll
> support src_configure too)

There's currently no mechanism for an ebuild or eclass to 'die' in
global scope.

It's something that could be available for future EAPIs without too
much difficulty, though... We discussed this for Exherbo, and decided
upon something like this:

* Add a new metadata key called BROKENNESS.

* Any ID with non-empty BROKENNESS is treated as being hard masked and
not unmaskable by the user, in the same way than an unknown EAPI is.

* Add a function which can only be called in global scope that adds an
item to BROKENNESS. This does *not* prevent further sourcing.

This one hopefully shouldn't be too hard to implement (Zac?). If people
are running into excessive difficulties with eclasses, it might be
worth doing an EAPI 3 quickly with just this addition...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 and src_configure in eclasses

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Sun, 5 Oct 2008 17:07:40 +0200
> Alexis Ballier <aballier@gentoo.org> wrote:
>> Maybe eclasses should die on unknown eapi; the fact is I really hate
>> the current way it's done when switching an ebuild to EAPI-2 which
>> uses an eclass that exports src_compile; most eclasses don't special
>> case eapi-2 yet and we end up running econf twice at best. I fear
>> that'll be the same with eapi-3, eapi-4, etc. (supposing that they'll
>> support src_configure too)
> 
> There's currently no mechanism for an ebuild or eclass to 'die' in
> global scope.

They can call 'die' in global scope. Perhaps it's not the nicest
thing to do, but it can be done.

> It's something that could be available for future EAPIs without too
> much difficulty, though... We discussed this for Exherbo, and decided
> upon something like this:
> 
> * Add a new metadata key called BROKENNESS.
> 
> * Any ID with non-empty BROKENNESS is treated as being hard masked and
> not unmaskable by the user, in the same way than an unknown EAPI is.
> 
> * Add a function which can only be called in global scope that adds an
> item to BROKENNESS. This does *not* prevent further sourcing.
> 
> This one hopefully shouldn't be too hard to implement (Zac?). If people
> are running into excessive difficulties with eclasses, it might be
> worth doing an EAPI 3 quickly with just this addition...
> 

Considering that they can already call 'die' in global scope I don't
see it as being that urgent.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjo9SsACgkQ/ejvha5XGaOUUQCfRSaJYF3xqWfaLVfE1M5lT0Fk
NDcAnikfPOu/6nnBZIXuKbUXptNIPyOP
=Lpc7
-----END PGP SIGNATURE-----

Re: [gentoo-dev] EAPI-2 and src_configure in eclasses

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

On Sun, 05 Oct 2008 10:11:08 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> They can call 'die' in global scope. Perhaps it's not the nicest
> thing to do, but it can be done.

Last time I tried it, Portage behaved rather horribly with global scope
dies. Is this still the case?

> Considering that they can already call 'die' in global scope I don't
> see it as being that urgent.

If we're considering global scope die to be a usable solution, we need
to start defining its behaviour and providing a way of tracking it in
metadata.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 and src_configure in eclasses

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Sun, 05 Oct 2008 10:11:08 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> They can call 'die' in global scope. Perhaps it's not the nicest
>> thing to do, but it can be done.
> 
> Last time I tried it, Portage behaved rather horribly with global scope
> dies. Is this still the case?

In terms of dependency resolution, the current behavior is to report
that the package is "masked by corruption".

>> Considering that they can already call 'die' in global scope I don't
>> see it as being that urgent.
> 
> If we're considering global scope die to be a usable solution, we need
> to start defining its behaviour and providing a way of tracking it in
> metadata.

Sure, we can add some bells and whistles. But like I said before, I
don't see it as being especially urgent. If an eclass uses 'die' as
an assertion, it's not something that should be triggered under
normal circumstances. It serves mostly a feedback mechanism which
quickly informs the developer when they've made a mistake that needs
to be corrected immediately.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjpIo0ACgkQ/ejvha5XGaOtrwCg4Q58XViLtI9/YNMz2hj6VX1k
y2QAoIHGMLelGKmIyYDYmZNmg61z0LUj
=iwn8
-----END PGP SIGNATURE-----

[gentoo-dev] Re: EAPI-2 and src_configure in eclasses

[Steve Long]

Alexis Ballier wrote:

> Indeed; different names could be given to different implementations of
> the same thing, but that might completely kill the point of abstracting
> it.
> Maybe eclasses should die on unknown eapi; the fact is I really hate the
> current way it's done when switching an ebuild to EAPI-2 which uses
> an eclass that exports src_compile; most eclasses don't special case
> eapi-2 yet and we end up running econf twice at best. I fear that'll be
> the same with eapi-3, eapi-4, etc. (supposing that they'll support
> src_configure too)
> 
>> > An EXPORT_FUNCTIONS ignoring any function its doesn't know for its
>> > eapi would help too.
>> 
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>> An EXPORT_FUNCTIONS ignoring incorrect usage makes one less place
>> checking for eclass screwups...
> 
> yes; that's just a matter of choice though, but for eclasses it's
> probably not luxury.
> 
Well it's simple enough to check (and give a QA warning) for unknown
functions; adding a check for a specific string prefix (or to exclude a
certain subset) in EXPORT_FUNCTIONS (based on current EAPI) is simple
enough too. Is that what you mean?

The behaviour to trigger could change eg for debug mode, or a repoman check.

I don't quite see how that deals with an eclass calling econf in its
exported src_compile? Seems like EAPI versioning for eclasses (with
implicit 0 only) is more what you're after for that issue (so the PM could
suppress src_configure if src_compile is going to resolve to an EAPI-0
eclass function, although the inheritance stack might prove problematic.)

Having to die for an unsupported EAPI seems like the wrong approach; if it's
not going to work the PM shouldn't source it. If it can be made to work by
filtering certain functions, that's doable.

In the worst case, an ebuild switching to EAPI will require eclass
maintenance; this is where the separation of elibs (useful code) and
eclasses (template ebuilds) would be useful, although that needs versioning
too.

Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses

[Alexis Ballier]

[-- Attachment #1: Type: text/plain, Size: 2156 bytes --]


> I don't quite see how that deals with an eclass calling econf in its
> exported src_compile? Seems like EAPI versioning for eclasses (with
> implicit 0 only) is more what you're after for that issue (so the PM
> could suppress src_configure if src_compile is going to resolve to an
> EAPI-0 eclass function, although the inheritance stack might prove
> problematic.)

I don't know of any way for the pm to detect if the eclass supports
given eapi or not, and even less if exported src_compile will be eapi-2
aware or not.

> Having to die for an unsupported EAPI seems like the wrong approach;
> if it's not going to work the PM shouldn't source it. If it can be
> made to work by filtering certain functions, that's doable.

I tend to see dying for an unsupported eapi as eclass versioning for
the poor people but that's the only thing we can do atm afaik. For now,
all eapi are backward compatible wrt to sourcing so that's not really
an issue to source an eapi-0 eclass withing an eapi-2 ebuild. I think
there has been a discussion on eclasses vs eapi before and the outcome
was that eclasses should add hacky checks for eapi; which means to me
we'll have to adjust those hacky checks for each new eapi.

However, for now, not dying allows workarounds like:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-video/ogmrip/ogmrip-0.12.2.ebuild?view=markup
but I don't consider it very pretty.

> In the worst case, an ebuild switching to EAPI will require eclass
> maintenance; this is where the separation of elibs (useful code) and
> eclasses (template ebuilds) would be useful, although that needs
> versioning too.

The problem will remain for this new definition of eclasses; glad to
see you're volunteering to fix every single eclass that exports a
src_compile/unpack function for eapi-2 :)

If by template ebuilds you mean the EXPORT_FUNCTIONS line and some deps,
then I dont see the difference between eapi versioning for eclasses and
a switch/case for each eapi in the unversioned eclass. Note that "useful
code" can differ upon eapi (I'm thinking about has_version checks).

Regards,

Alexis.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses

[Alec Warner]

I don't want to be the guy that kicks people off lists; but I will do
it; so keep the thread on topic[0] and be nice[1].  I know everyone
here is capable of that.  Feel free to sling the personal crap
comments somewhere more appropriate (such as a personal diary, blog,
or in verbal complaints to a spouse or drinking buddy.)  Remember that
text is hard to communicate through and regardless of any intentions,
people are judged by how they are perceived and 'helpful' intentions
may not come off quite as helpful as some would like; chose your words
carefully.

Consider this your first and last warning from Userrel.

-Alec

[0] Subject: Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses
[1] http://www.gentoo.org/proj/en/council/coc.xml

[gentoo-dev] Re: EAPI-2 and src_configure in eclasses

[Duncan]

"Alec Warner" <antarus@gentoo.org> posted
b41005390810100017w3ca0b0c9ta8c37cb15ccdb473@mail.gmail.com, excerpted
below, on  Fri, 10 Oct 2008 00:17:14 -0700:

> Consider this your first and last warning from Userrel.

FWIW... at least on gmane, that appears as a response to aballier (gentoo 
dev), with references headers indicating the same thing, but given that 
(1) there was no attribution or quote so it's not possible to say who it 
was intended for directly, (2) I didn't see what was offensive in his 
post, and (3) that the warning was from userrel not devrel, I believe the 
warning was intended for someone other than the direct parent (my 
grandparent) poster.

IOW, aballier may be very confused right about now... I know I was but at 
least it's not my posts in the balance like his appear to be, while 
someone else (my public attempt at a guess who wouldn't help) may be 
missing a warning they need to see (tho hopefully they got the message in 
any case).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses

[Alec Warner]

On Fri, Oct 10, 2008 at 5:41 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> "Alec Warner" <antarus@gentoo.org> posted
> b41005390810100017w3ca0b0c9ta8c37cb15ccdb473@mail.gmail.com, excerpted
> below, on  Fri, 10 Oct 2008 00:17:14 -0700:
>
>> Consider this your first and last warning from Userrel.
>
> FWIW... at least on gmane, that appears as a response to aballier (gentoo
> dev), with references headers indicating the same thing, but given that
> (1) there was no attribution or quote so it's not possible to say who it
> was intended for directly, (2) I didn't see what was offensive in his
> post, and (3) that the warning was from userrel not devrel, I believe the
> warning was intended for someone other than the direct parent (my
> grandparent) poster.
>
> IOW, aballier may be very confused right about now... I know I was but at
> least it's not my posts in the balance like his appear to be, while
> someone else (my public attempt at a guess who wouldn't help) may be
> missing a warning they need to see (tho hopefully they got the message in
> any case).

Assume the warning was for the whole list; I just replied to the last
message in the thread; blame gmail ;)

-Alec

>
> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
>
>
>

Re: [gentoo-dev] EAPI-2 and src_configure in eclasses

[Ulrich Mueller]

>>>>> On Sun, 5 Oct 2008, Alexis Ballier wrote:

> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>> Export it if and only if EAPI is 2.

> By the way, do we really want to special case eapi-2 in every eclass ?
> That's lot of code duplication and will get even worse when we'll reach
> eapi-42. That would have been cool to have a pm function that tells
> "has my eapi foo support" but that sort of bites its tail that way.

Hm, what about:
[ "$(type -t src_configure)" == function ] && EXPORT_FUNCTIONS src_configure

Or is this too fragile or trying to be too clever?

Ulrich

Re: [gentoo-dev] EAPI-2 and src_configure in eclasses

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

On Sun, 5 Oct 2008 17:38:11 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> > By the way, do we really want to special case eapi-2 in every
> > eclass ? That's lot of code duplication and will get even worse
> > when we'll reach eapi-42. That would have been cool to have a pm
> > function that tells "has my eapi foo support" but that sort of
> > bites its tail that way.
> 
> Hm, what about:
> [ "$(type -t src_configure)" == function ] && EXPORT_FUNCTIONS
> src_configure
> 
> Or is this too fragile or trying to be too clever?

It's illegal, according to PMS. It also won't work with Paludis, since
phase function definitions aren't made available until just before that
phase executes (there is a reason for this -- it provides us with a way
of identifying whether a package has a particular phase or not).

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: EAPI-2 and src_configure in eclasses

[Steve Long]

Ciaran McCreesh wrote:

> On Sun, 5 Oct 2008 17:38:11 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
>> > By the way, do we really want to special case eapi-2 in every
>> > eclass ? That's lot of code duplication and will get even worse
>> > when we'll reach eapi-42. That would have been cool to have a pm
>> > function that tells "has my eapi foo support" but that sort of
>> > bites its tail that way.
>> 
>> Hm, what about:
>> [ "$(type -t src_configure)" == function ] && EXPORT_FUNCTIONS
>> src_configure
>> 
>> Or is this too fragile or trying to be too clever?
> 
> It's illegal, according to PMS. It also won't work with Paludis, since
> phase function definitions aren't made available until just before that
> phase executes (there is a reason for this -- it provides us with a way
> of identifying whether a package has a particular phase or not).
> 
That seems a bit implementation-specific; how one alternative package
manager generates that metadata isn't important (though it does seem odd
that you think it has to be done at that point) nor should it get in the
way.

Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

On Tue, 07 Oct 2008 17:07:21 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> > It's illegal, according to PMS. It also won't work with Paludis,
> > since phase function definitions aren't made available until just
> > before that phase executes (there is a reason for this -- it
> > provides us with a way of identifying whether a package has a
> > particular phase or not).
> > 
> That seems a bit implementation-specific; how one alternative package
> manager generates that metadata isn't important (though it does seem
> odd that you think it has to be done at that point) nor should it get
> in the way.

The whole point of PMS is that it provides a way to avoid relying upon
implementation specific things. There are currently no packages that
rely upon calling phase functions in the wrong place, and there are
good reasons a package manager might want to avoid implementing things
in a way such that doing so is legal, so we don't allow it.

Also, I don't think it has to be done at that point. I think it's
convenient to do it at that point, and when combined with several other
reasons doing it that way is the best option.

Strange how you repeatedly seem to pop up in favour of doing whatever
you think will cause most inconvenience to Paludis, though...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] [project] Re: Re: EAPI-2 and src_configure in eclasses

[Steve Long]

Ciaran McCreesh wrote:

> On Tue, 07 Oct 2008 17:07:21 +0100
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> > It's illegal, according to PMS. It also won't work with Paludis,
>> > since phase function definitions aren't made available until just
>> > before that phase executes (there is a reason for this -- it
>> > provides us with a way of identifying whether a package has a
>> > particular phase or not).
>> > 
>> That seems a bit implementation-specific; how one alternative package
>> manager generates that metadata isn't important (though it does seem
>> odd that you think it has to be done at that point) nor should it get
>> in the way.
> 
> The whole point of PMS is that it provides a way to avoid relying upon
> implementation specific things. There are currently no packages that
> rely upon calling phase functions in the wrong place
It wasn't about calling it in the wrong place, it was about how you test for
whether the ebuild+eclasses provide a function, or use a phase.

> and there are 
> good reasons a package manager might want to avoid implementing things
> in a way such that doing so is legal, so we don't allow it.
>
Sure let's keep constraining what the bash side of things can do, as that's
nothing to do with the package manager implementation.
 
> Also, I don't think it has to be done at that point. I think it's
> convenient to do it at that point, and when combined with several other
> reasons doing it that way is the best option.
>
Yes, a mystery wrapped in an enigma wrapped in pure bullsh^W obfuscation is
always such fun.
 
> Strange how you repeatedly seem to pop up in favour of doing whatever
> you think will cause most inconvenience to Paludis, though...
> 
Strange how you think you can read my mind.. I actually think that not
providing functions an ebuild might call in a phase, during the actual
install, is not such a good way for the mangler to ascertain ahead of time
whether or not that phase will be needed, *irrespective* of how any extant
implementation does it. But as you always remind me, I don't know enough to
comment-- because you say so.

I actually hesitated to get into that discussion with you. I did so as I
wanted to query the design decision. You know, a technical _discussion_..
Thanks for reminding me again how incapable of that you are, unless you
think there is some political capital to be gained.

Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

On Tue, Oct 07, 2008 at 05:07:21PM +0100, Steve Long wrote:
> Ciaran McCreesh wrote:
> 
> > On Sun, 5 Oct 2008 17:38:11 +0200
> > Ulrich Mueller <ulm@gentoo.org> wrote:
> >> > By the way, do we really want to special case eapi-2 in every
> >> > eclass ? That's lot of code duplication and will get even worse
> >> > when we'll reach eapi-42. That would have been cool to have a pm
> >> > function that tells "has my eapi foo support" but that sort of
> >> > bites its tail that way.
> >> 
> >> Hm, what about:
> >> [ "$(type -t src_configure)" == function ] && EXPORT_FUNCTIONS
> >> src_configure
> >> 
> >> Or is this too fragile or trying to be too clever?
> > 
> > It's illegal, according to PMS. It also won't work with Paludis, since
> > phase function definitions aren't made available until just before that
> > phase executes (there is a reason for this -- it provides us with a way
> > of identifying whether a package has a particular phase or not).
> > 
> That seems a bit implementation-specific; how one alternative package
> manager generates that metadata isn't important (though it does seem odd
> that you think it has to be done at that point) nor should it get in the
> way.

Actually both alternative PM's do this now (>=pkgcore-0.4.7.9), 
although in pkgcore's case the default phase functions are installed 
after sourcing rather then at the time of invocation.

Long term, this is the correct way to go imo- the downside to it is 
that a common sourcing env needs be defined at some point (newdepend, 
newrdepend, etc) to avoid any question of what's available.

~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]