On 04/23/2010 08:14 AM, James Cloos wrote:
HvD == Harald van Dijk true...@gentoo.org writes:
HvD Let's say this is in the tree:
HvD foo.eclass:
HvD DEPEND=dev-lang/python:2.6
HvD bar-1.ebuild:
HvD inherit foo
HvD Let's say this is in your overlay:
HvD foo.eclass:
HvD DEPEND=|| (
HvD == Harald van Dijk true...@gentoo.org writes:
HvD Let's say this is in the tree:
HvD foo.eclass:
HvD DEPEND=dev-lang/python:2.6
HvD bar-1.ebuild:
HvD inherit foo
HvD Let's say this is in your overlay:
HvD foo.eclass:
HvD DEPEND=|| ( dev-lang/python:3.1 dev-lang/python:2.6 )
HvD Now you
CM == Ciaran McCreesh ciaran.mccre...@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
On Mon, Apr 19, 2010 at 04:58:57PM -0400, James Cloos wrote:
CM == Ciaran McCreesh ciaran.mccre...@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
On Fri, 16 Apr 2010 22:30:46 -0500
Steev Klimaszewski st...@gentoo.org wrote:
On Fri, Apr 16, 2010 at 3:28 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Fri, 16 Apr 2010 16:23:48 -0400
James Cloos cl...@jhcloos.com wrote:
OK. Let me rephrase. Portage does not need to
CM == Ciaran McCreesh ciaran.mccre...@googlemail.com writes:
CM Users aren't responsible...
Even if that is or were so, it is irrelevant. It is ther user's box,
and therefore the users' preference is the only valid choice.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP:
ZM == Zac Medico zmed...@gentoo.org writes:
ZM It's called eclass-overrides and it's been mentioned earlier in the thread.
But that is useless unless you ignore the metadata cache. And ignoring the
metadata cache makes portage unusably slow.
It needs to work exacly as I described it.
And
ZM == Zac Medico zmed...@gentoo.org writes:
Portage does not need to validate eclass changes.
ZM Then how do you propose that it handles metadata changes that are
ZM attributed to eclass changes? For example, see the issue they had
ZM with vmware.eclass changes in this bug:
ZM
On Fri, 16 Apr 2010 16:23:48 -0400
James Cloos cl...@jhcloos.com wrote:
OK. Let me rephrase. Portage does not need to validate local
changes.
Sure it does. If it doesn't, and your local changes affect metadata,
horrible things happen.
If a user uses a local eclass to override one in portage
On Fri, Apr 16, 2010 at 3:28 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Fri, 16 Apr 2010 16:23:48 -0400
James Cloos cl...@jhcloos.com wrote:
OK. Let me rephrase. Portage does not need to validate local
changes.
Sure it does. If it doesn't, and your local changes affect
ZM == Zac Medico zmed...@gentoo.org writes:
ZM On 04/06/2010 07:22 AM, James Cloos wrote:
ZM == Zac Medico zmed...@gentoo.org writes:
ZM You can configure eclass override behavior via eclass-overrides in
ZM /etc/portage/repos.conf, as documented in `man portage`.
, From that manpage
A reasonable alternative would be to have a separate variable in make.conf,
such as ECLASS_OVERLAY_DIRS, which specifies acceptable overlays for eclasses.
In most cases, users would probably only have their own, local overlay there,
and any eclasses found there should be used in preference to any
On Mon, Apr 12, 2010 at 01:30:21PM -0400, James Cloos wrote:
A reasonable alternative would be to have a separate variable in make.conf,
such as ECLASS_OVERLAY_DIRS, which specifies acceptable overlays for eclasses.
In most cases, users would probably only have their own, local overlay there,
On 04/12/2010 10:17 AM, James Cloos wrote:
ZM == Zac Medico zmed...@gentoo.org writes:
ZM On 04/06/2010 07:22 AM, James Cloos wrote:
ZM == Zac Medico zmed...@gentoo.org writes:
ZM You can configure eclass override behavior via eclass-overrides in
ZM /etc/portage/repos.conf, as documented
On 04/12/2010 11:00 AM, Brian Harring wrote:
On Mon, Apr 12, 2010 at 01:30:21PM -0400, James Cloos wrote:
A reasonable alternative would be to have a separate variable in make.conf,
such as ECLASS_OVERLAY_DIRS, which specifies acceptable overlays for
eclasses.
In most cases, users would
ZM == Zac Medico zmed...@gentoo.org writes:
ZM You can configure eclass override behavior via eclass-overrides in
ZM /etc/portage/repos.conf, as documented in `man portage`.
, From that manpage
| When using eclass-overrides, due to bug #276264, you must ensure that
| your portage tree does
On 04/06/2010 07:22 AM, James Cloos wrote:
ZM == Zac Medico zmed...@gentoo.org writes:
ZM You can configure eclass override behavior via eclass-overrides in
ZM /etc/portage/repos.conf, as documented in `man portage`.
, From that manpage
| When using eclass-overrides, due to bug
TV == Torsten Veller ml...@veller.net writes:
One change the perl eclasses require is elimination of the code which
deletes the man pages.
Deleting the man pages is /extremely/ rude and should not occur.
And given that portage inappropriately ignores a fixed eclass in the
OVERlay, that means
On 04/01/2010 04:41 PM, James Cloos wrote:
And given that portage inappropriately ignores a fixed eclass in the
OVERlay, that means that every time one syncs one must re-patch the
offending eclasses.
You can configure eclass override behavior via eclass-overrides in
/etc/portage/repos.conf, as
On Thu, Apr 01, 2010 at 05:14:20PM -0700, Zac Medico wrote:
You can configure eclass override behavior via eclass-overrides in
/etc/portage/repos.conf, as documented in `man portage`. There are a
number of caveats to eclass-overrides, and that's why it's not the
default behavior. For example,
On 04/01/2010 05:17 PM, Brian Harring wrote:
On Thu, Apr 01, 2010 at 05:14:20PM -0700, Zac Medico wrote:
You can configure eclass override behavior via eclass-overrides in
/etc/portage/repos.conf, as documented in `man portage`. There are a
number of caveats to eclass-overrides, and that's why
On Tue, Mar 30, 2010 at 4:11 AM, Torsten Veller ml...@veller.net wrote:
The perl-module.eclass must be updated to support EAPI=3 [1] and
a new eclass will be added which does contain some (more or less) useful
stand-alone functions split from the old perl-module.eclass without
exporting phase
22 matches
Mail list logo
