public inbox for gentoo-project@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project]  [project] Re: Re: EAPI-2 and src_configure in eclasses
Date: Wed, 8 Oct 2008 20:14:33 +0100	[thread overview]
Message-ID: <20081008201433.737bdc35@snowmobile> (raw)
In-Reply-To: <gcivv6$26m$1@ger.gmane.org>

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

On Wed, 08 Oct 2008 19:48:56 +0100
Steve Long <slong@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.

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

  reply	other threads:[~2008-10-08 19:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <18664.49886.385742.36918@a1ihome1.kph.uni-mainz.de>
     [not found] ` <20081005150727.15d307c6@googlemail.com>
     [not found]   ` <20081005161546.31446f38@gentoo.org>
     [not found]     ` <18664.57187.605226.301832@a1ihome1.kph.uni-mainz.de>
     [not found]       ` <20081005164158.0b27b3af@googlemail.com>
     [not found]         ` <gcg23k$dt3$1@ger.gmane.org>
     [not found]           ` <20081007173322.17edc8bd@googlemail.com>
2008-10-08 18:48             ` [gentoo-project] [project] Re: Re: EAPI-2 and src_configure in eclasses Steve Long
2008-10-08 19:14               ` Ciaran McCreesh [this message]
2008-10-09  0:55                 ` [gentoo-project] [LONG] " Steve Long
2008-10-09  1:40                   ` Ciaran McCreesh
2008-10-11  3:45                     ` [gentoo-project] " Steve Long
2008-10-11 15:38                       ` Ciaran McCreesh
2008-10-11 15:45                         ` Dawid Węgliński
2008-10-11 23:08                           ` Ciaran McCreesh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081008201433.737bdc35@snowmobile \
    --to=ciaran.mccreesh@googlemail.com \
    --cc=gentoo-project@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox