Gentoo Logo
Gentoo Spaceship




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-project
Navigation:
Lists: gentoo-project: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-project@g.o
From: Ciaran McCreesh <ciaran.mccreesh@...>
Subject: Re: [LONG] Re: EAPI-2 and src_configure in eclasses
Date: Thu, 9 Oct 2008 02:40:38 +0100
On Thu, 09 Oct 2008 01:55:41 +0100
Steve Long <slong@...> 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
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.

> IIRC weren't you the guy who deliberately took a troll as your avatar
> in order to flagrantly ban-evade and troll the forums a while back?

Uh. No.

> > It is of course highly obvious that there are 
> > several ways of achieving the desired result, and highly obvious
> > that there are a whole bunch of factors affecting which one works
> > best.
> >
> Yes, but it's not something we can discuss, I know, because I am
> 'obviously' too stupid to understand.

If you genuinely care about how Paludis deals with the bash side of
things, do a little background reading and then post a mail to the
Paludis mailing list asking about it. The answer you get will be long,
obscure and of interest to maybe three people, and only because they
have to know about it when changing things.

> > As it happens, all three package managers picked different
> > solutions, all based upon extremely obscure internals issues.
> 
> I read that as "stuff I don't really understand." No doubt you'll
> elucidate over the next 20 mails or so.. I'll get back to you then.

I realise trying to extend the scope of what you expect me to explain
to include life, the universe and everything so you can moan that at me
that I didn't include a demonstration of why the sky is blue in my
original email is your strategy here, but really... Do you genuinely
care?

> > Which brings me back 
> > to my original point -- mandating a particular behaviour to enable
> > some horrible ebuild hackery that doesn't even do what people want
> > would be a very silly decision.
> >
> You mean the hackery one might use to detect whether a phase is
> needed?

It won't, though, because the meaning of phases and phase functions
changes between EAPIs. Which is also something that's already been
covered.
 
> >> 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.
> > 
> > Your premise is faulty. Ebuilds may not call phase functions, and
> > never do.
> >
> 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.

> Is any of that true? Does it matter? What does any of it have to do
> with software development? Would you like a full CV, passport and
> biometric data from everyone who posts? Who are you to impose that
> condition?

No, I would like you to stop maintaining a "real work" persona and a
"paludis bashing" persona. Beyond that I don't care.

Incidentally, read up on luke-jr (google "gentoo-dev seems to be
hacked") if you want to see what Gentoo's view on using aliases and
contributions from non-existent people is.

> You weaseled out of signing the copyright transfer and continue to
> wave it in everyone's face at the slightest opportunity. Excuse me
> for not being bowled-over.

Uh. Huh.

-- 
Ciaran McCreesh
Attachment:
signature.asc (PGP signature)
Replies:
Re: [LONG] Re: EAPI-2 and src_configure in eclasses
-- Steve Long
References:
[project] Re: Re: EAPI-2 and src_configure in eclasses
-- Steve Long
Re: [project] Re: Re: EAPI-2 and src_configure in eclasses
-- Ciaran McCreesh
[LONG] Re: EAPI-2 and src_configure in eclasses
-- Steve Long
Navigation:
Lists: gentoo-project: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
[LONG] Re: EAPI-2 and src_configure in eclasses
Next by thread:
Re: [LONG] Re: EAPI-2 and src_configure in eclasses
Previous by date:
[LONG] Re: EAPI-2 and src_configure in eclasses
Next by date:
Returning dev: Patrick Lauer (patrick)


Updated Jun 17, 2009

Summary: Archive of the gentoo-project mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.