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: [project] Re: Re: EAPI-2 and src_configure in eclasses
Date: Wed, 8 Oct 2008 20:14:33 +0100
On Wed, 08 Oct 2008 19:48:56 +0100
Steve Long <slong@...> 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.

We were discussing your trollish claim that I thought that things had to
be done a particular way. 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.

As it happens, all three package managers picked different solutions,
all based upon extremely obscure internals issues. 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.

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

Your premise is faulty. Ebuilds may not call phase functions, and
never do.

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

If you want a technical discussion, post using your other account with
your real name on it, not your sockpuppet. It's a bit hard to take you
seriously when you maintain two personas, one for real development and
an alterego for Pkgcore fanboyism / Paludis bashing.

-- 
Ciaran McCreesh
Attachment:
signature.asc (PGP signature)
Replies:
[LONG] Re: EAPI-2 and src_configure in eclasses
-- Steve Long
References:
[project] Re: 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:
[project] Re: Re: EAPI-2 and src_configure in eclasses
Next by thread:
[LONG] Re: EAPI-2 and src_configure in eclasses
Previous by date:
[project] Re: Re: EAPI-2 and src_configure in eclasses
Next by date:
[LONG] Re: EAPI-2 and src_configure in eclasses


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.