gmane.linux.gentoo.devel

Ulrich Mueller | 5 Oct 15:32

EAPI-2 and src_configure in eclasses

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

Ciaran McCreesh | 5 Oct 16:07

Re: EAPI-2 and src_configure in eclasses

On Sun, 5 Oct 2008 15:36:30 +0200
Ulrich Mueller <ulm <at> 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

Alexis Ballier | 5 Oct 16:15

Re: EAPI-2 and src_configure in eclasses

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

> On Sun, 5 Oct 2008 15:36:30 +0200
> Ulrich Mueller <ulm <at> 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.

Ciaran McCreesh | 5 Oct 16:24

Re: EAPI-2 and src_configure in eclasses

On Sun, 5 Oct 2008 16:15:46 +0200
Alexis Ballier <aballier <at> 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

Alexis Ballier | 5 Oct 17:07

Re: EAPI-2 and src_configure in eclasses

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

> On Sun, 5 Oct 2008 16:15:46 +0200
> Alexis Ballier <aballier <at> 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...

(Continue reading)

Ciaran McCreesh | 5 Oct 17:17

Re: EAPI-2 and src_configure in eclasses

On Sun, 5 Oct 2008 17:07:40 +0200
Alexis Ballier <aballier <at> 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

(Continue reading)

Zac Medico | 5 Oct 19:11

Re: EAPI-2 and src_configure in eclasses


Ciaran McCreesh wrote:
> On Sun, 5 Oct 2008 17:07:40 +0200
> Alexis Ballier <aballier <at> 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

(Continue reading)

Ciaran McCreesh | 5 Oct 22:03

Re: EAPI-2 and src_configure in eclasses

On Sun, 05 Oct 2008 10:11:08 -0700
Zac Medico <zmedico <at> 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

Zac Medico | 5 Oct 22:24

Re: EAPI-2 and src_configure in eclasses


Ciaran McCreesh wrote:
> On Sun, 05 Oct 2008 10:11:08 -0700
> Zac Medico <zmedico <at> 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

(Continue reading)

Steve Long | 7 Oct 17:49

Re: EAPI-2 and src_configure in eclasses

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 <at> 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

(Continue reading)

Alexis Ballier | 9 Oct 10:26

Re: Re: EAPI-2 and src_configure in eclasses


> 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

(Continue reading)

Alec Warner | 10 Oct 09:17

Re: Re: EAPI-2 and src_configure in eclasses

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

Duncan | 10 Oct 14:41

Re: EAPI-2 and src_configure in eclasses

"Alec Warner" <antarus <at> gentoo.org> posted
b41005390810100017w3ca0b0c9ta8c37cb15ccdb473 <at> 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

Alec Warner | 10 Oct 18:06

Re: Re: EAPI-2 and src_configure in eclasses

On Fri, Oct 10, 2008 at 5:41 AM, Duncan <1i5t5.duncan <at> cox.net> wrote:
> "Alec Warner" <antarus <at> gentoo.org> posted
> b41005390810100017w3ca0b0c9ta8c37cb15ccdb473 <at> 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 --

(Continue reading)

Ulrich Mueller | 5 Oct 17:38

Re: EAPI-2 and src_configure in eclasses

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

> Ciaran McCreesh <ciaran.mccreesh <at> 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

Ciaran McCreesh | 5 Oct 17:41

Re: EAPI-2 and src_configure in eclasses

On Sun, 5 Oct 2008 17:38:11 +0200
Ulrich Mueller <ulm <at> 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

Steve Long | 7 Oct 18:07

Re: EAPI-2 and src_configure in eclasses

Ciaran McCreesh wrote:

> On Sun, 5 Oct 2008 17:38:11 +0200
> Ulrich Mueller <ulm <at> 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.

Ciaran McCreesh | 7 Oct 18:33

Re: Re: EAPI-2 and src_configure in eclasses

On Tue, 07 Oct 2008 17:07:21 +0100
Steve Long <slong <at> 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

Steve Long | 8 Oct 20:48

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

Ciaran McCreesh wrote:

> On Tue, 07 Oct 2008 17:07:21 +0100
> Steve Long <slong <at> 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

(Continue reading)

Ciaran McCreesh | 8 Oct 21:14

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

On Wed, 08 Oct 2008 19:48:56 +0100
Steve Long <slong <at> rathaus.eclipse.co.uk> wrote:
> > 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.

The two issues are the same.

> > 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.

There are lots of constraints on what the bash side can do that are
for package manager implementation sanity reasons. The whole
constant cache requirement thing, for example, is purely a side effect
of how package managers work.

> > 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.

(Continue reading)

Steve Long | 9 Oct 02:55

[LONG] Re: EAPI-2 and src_configure in eclasses

*Sigh* Guess it's that time of year again..

Ciaran McCreesh wrote:
> Steve Long <slong <at> rathaus.eclipse.co.uk> wrote:
>> > 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.
> 
> The two issues are the same.
>
You mean the three? They all boil down to whether a function is declared,
yes. Have a cookie: you'll need it.

>> > 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.
> 
> There are lots of constraints on what the bash side can do that are
> for package manager implementation sanity reasons. The whole
> constant cache requirement thing, for example, is purely a side effect
> of how package managers work.
>
Yes and it's well understood and has been discussed on the list. This

(Continue reading)

Ciaran McCreesh | 9 Oct 03:40

Re: [LONG] Re: EAPI-2 and src_configure in eclasses

On Thu, 09 Oct 2008 01:55:41 +0100
Steve Long <slong <at> rathaus.eclipse.co.uk> wrote:
> >> 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.
> > 
> > The two issues are the same.
> >
> You mean the three? They all boil down to whether a function is
> declared, yes. Have a cookie: you'll need it.

So if you know they're the same, why did you say that it's about
something else?

> > There are lots of constraints on what the bash side can do that are
> > for package manager implementation sanity reasons. The whole
> > constant cache requirement thing, for example, is purely a side
> > effect of how package managers work.
> >
> Yes and it's well understood and has been discussed on the list. This
> hasn't, to my knowledge, yet everytime something which has /not/ been
> discussed is brought up, you rear up spouting on about vague hints of
> doom to do with portage, irrespective of how many Gentoo systems it's
> built and maintains. You obfuscate and spam the list with 15 mails
> instead of simply explaining in one go.

Uhm. No. My original post explained it all in a level of detail
suitable for the issue at hand. Unfortunately, you then had to jump in
and expect me to explain twenty other at best vaguely related issues
which weren't under discussion. As I've said every time you make that

(Continue reading)

Steve Long | 11 Oct 05:45

Re: [LONG] Re: EAPI-2 and src_configure in eclasses

Ciaran McCreesh wrote:
> On Thu, 09 Oct 2008 01:55:41 +0100
> Steve Long <slong <at> rathaus.eclipse.co.uk> wrote:
>> >> 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.
>> > 
>> > The two issues are the same.
>> >
>> You mean the three? They all boil down to whether a function is
>> declared, yes. Have a cookie: you'll need it.
> 
> So if you know they're the same, why did you say that it's about
> something else?
>
*cough* user perception vs reality; in your case there's at least a third
level going on ofc.

>> > There are lots of constraints on what the bash side can do that are
>> > for package manager implementation sanity reasons. The whole
>> > constant cache requirement thing, for example, is purely a side
>> > effect of how package managers work.
>> >
>> Yes and it's well understood and has been discussed on the list. This
>> hasn't, to my knowledge, yet everytime something which has /not/ been
>> discussed is brought up, you rear up spouting on about vague hints of
>> doom to do with portage, irrespective of how many Gentoo systems it's
>> built and maintains. You obfuscate and spam the list with 15 mails
>> instead of simply explaining in one go.
>

(Continue reading)

Ciaran McCreesh | 11 Oct 17:38

Re: Re: [LONG] Re: EAPI-2 and src_configure in eclasses

On Sat, 11 Oct 2008 04:45:16 +0100
Steve Long <slong <at> rathaus.eclipse.co.uk> wrote:
> > As I've said every time you make that 
> > absurd claim, this is not the place to post a two hundred page
> > explanation of how every last bit of the computer works, from
> > electrons upwards, in response to a simple question.
> >
> Yes because we really need to discuss transistor logic for this.

Right, in the same way we need to discuss package manager loading
internals for this.

> >> you keep making things much more personal than they need to be.
> >> I was discussing how and when that metadata is generated. As
> >> Harring pointed out, pkgcore does it at a _different_ point in
> >> time.
> 
> Funny how that slipped by, isn't it?

What? I already mentioned how there were other obscure internals
factors related to the decision. There are all kinds of ways one could
do it. As it happens, I don't like the Pkgcore way primarily because it
directly encourages the kind of screwups that happened with the first
Pkgcore EAPI 2 attempt.

> (and no doubt your sekrit personality on the forums.)

Unlike you, I don't post from multiple accounts or pretending to be
several people. (As an aside: if you feel you must carry on calling me
a terrorist baby-munching communist or whatever it is this week, please

(Continue reading)

Dawid Węgliński | 11 Oct 17:45

Re: Re: [LONG] Re: EAPI-2 and src_configure in eclasses

On Saturday 11 of October 2008 17:38:54 Ciaran McCreesh wrote:

> > >> Hehe. You're good at that trick: you know full well I don't mean
> > >> the .ebuild
> > >
> > > So, uh, if by "an ebuild" you don't mean "the .ebuild", what do you
> > > mean? Kindly explain.
> >
> > Work it out, genius.
>
> I'm sorry, I can't work that out on my own. Please elucidate. Help me
> to understand why you think PMS is wrong with its restrictions on phase
> functions.

ebuild.sh, methinks.

Ciaran McCreesh | 12 Oct 01:08

Re: Re: [LONG] Re: EAPI-2 and src_configure in eclasses

On Sat, 11 Oct 2008 17:45:15 +0200
Dawid Węgliński <cla <at> gentoo.org> wrote:
> > I'm sorry, I can't work that out on my own. Please elucidate. Help
> > me to understand why you think PMS is wrong with its restrictions
> > on phase functions.
> 
> ebuild.sh, methinks.

If that's what he means, it's extremely bizarre, because none of the
package managers implement phase function execution as a simple direct
call. There's too much other stuff that needs doing before and after.

--

-- 
Ciaran McCreesh

Brian Harring | 8 Oct 05:21

Re: Re: EAPI-2 and src_configure in eclasses

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 <at> 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.

(Continue reading)

Return

Return to gmane.linux.gentoo.devel.

Advertisement

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane