From: "Harald van Dijk" <truedfx@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
Date: Mon, 19 Apr 2010 23:46:17 +0200 [thread overview]
Message-ID: <20100419214617.GA23143@boostbox> (raw)
In-Reply-To: <m3zl0zw43i.fsf@lugabout.jhcloos.org>
On Mon, Apr 19, 2010 at 04:58:57PM -0400, James Cloos wrote:
> >>>>> "CM" == Ciaran McCreesh <ciaran.mccreesh@googlemail.com> writes:
>
> CM> There's no need to offer the user the choice to do something that is
> CM> always broken. Your car doesn't have a "connect the exhaust fumes to
> CM> the air conditioning intake" button.
>
> Overriding portage's eclasses with one's own is not "always broken";
> your analogy is not at all on point.
Overriding portage's eclasses with your own is already possible. You're
asking to override portage's eclasses, without letting portage handle
the fact that you are overriding eclasses. And that is a bad idea. You
haven't commented, at least not in this thread that I have seen, on
how to handle metadata changes as a result of eclass changes.
Let's say this is in the tree:
foo.eclass:
DEPEND="dev-lang/python:2.6"
bar-1.ebuild:
inherit foo
Let's say this is in your overlay:
foo.eclass:
DEPEND="|| ( dev-lang/python:3.1 dev-lang/python:2.6 )"
Now you install bar. How should portage know that it must regenerate the
metadata cache, to see that it doesn't need to install python 2.6 if you
already have 3.1?
next prev parent reply other threads:[~2010-04-19 21:46 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-30 11:11 [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass Torsten Veller
2010-03-30 15:48 ` Alec Warner
2010-04-03 10:33 ` [gentoo-dev] " Torsten Veller
2010-04-01 23:41 ` [gentoo-dev] " James Cloos
2010-04-02 0:12 ` [gentoo-dev] " Jonathan Callen
2010-04-02 0:14 ` [gentoo-dev] " Zac Medico
2010-04-02 0:17 ` Brian Harring
2010-04-02 0:25 ` Zac Medico
2010-04-06 14:22 ` James Cloos
2010-04-06 18:39 ` Zac Medico
2010-04-12 17:17 ` James Cloos
2010-04-12 17:30 ` James Cloos
2010-04-12 18:00 ` Brian Harring
2010-04-12 22:55 ` Zac Medico
2010-04-16 20:00 ` James Cloos
2010-04-12 22:47 ` Zac Medico
2010-04-16 20:23 ` James Cloos
2010-04-16 20:28 ` Ciaran McCreesh
2010-04-17 3:30 ` Steev Klimaszewski
2010-04-17 7:13 ` Ciaran McCreesh
2010-04-18 3:28 ` James Cloos
2010-04-18 7:45 ` Ciaran McCreesh
2010-04-19 20:59 ` James Cloos
2010-04-19 21:46 ` Harald van Dijk [this message]
2010-04-23 15:14 ` James Cloos
2010-04-25 6:16 ` Zac Medico
2010-04-03 10:33 ` [gentoo-dev] " Torsten Veller
2010-04-04 8:25 ` Michael Higgins
2010-04-06 14:27 ` James Cloos
2010-04-06 14:52 ` Duncan
2010-04-10 0:40 ` James Cloos
2010-04-06 14:25 ` James Cloos
2010-04-06 16:00 ` Michał Górny
2010-04-10 0:34 ` James Cloos
2010-04-17 20:07 ` Torsten Veller
2010-04-12 8:07 ` Christian Faulhammer
2010-04-12 9:03 ` Fabian Groffen
2010-04-20 6:49 ` Torsten Veller
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=20100419214617.GA23143@boostbox \
--to=truedfx@gentoo.org \
--cc=gentoo-dev@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