On 04/23/2010 08:14 AM, James Cloos wrote:
>> "HvD" == Harald van Dijk 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>
> "HvD" == Harald van Dijk 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
On Mon, Apr 19, 2010 at 04:58:57PM -0400, James Cloos wrote:
> > "CM" == Ciaran McCreesh 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.
>
> "CM" == Ciaran McCreesh 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";
yo
On Sat, 17 Apr 2010 23:28:17 -0400
James Cloos wrote:
> > "CM" == Ciaran McCreesh 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.
There's no need to offer t
> "CM" == Ciaran McCreesh 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 OpenPGP: 1024D/ED7DAEA6
On Fri, 16 Apr 2010 22:30:46 -0500
Steev Klimaszewski wrote:
> On Fri, Apr 16, 2010 at 3:28 PM, Ciaran McCreesh
> wrote:
> > On Fri, 16 Apr 2010 16:23:48 -0400
> > James Cloos wrote:
> >> OK. Let me rephrase. Portage does not need to validate local
> >> changes.
> >
> > Sure it does. If it doe
On Fri, Apr 16, 2010 at 3:28 PM, Ciaran McCreesh
wrote:
> On Fri, 16 Apr 2010 16:23:48 -0400
> James Cloos 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.
Why n
On Fri, 16 Apr 2010 16:23:48 -0400
James Cloos 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 or in some
> r
> "ZM" == Zac Medico 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> http://bugs.gentoo.
> "ZM" == Zac Medico 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 lets not forge
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
On 04/12/2010 10:17 AM, James Cloos wrote:
>> "ZM" == Zac Medico writes:
>
> ZM> On 04/06/2010 07:22 AM, James Cloos wrote:
"ZM" == Zac Medico writes:
>>>
> ZM> You can configure eclass override behavior via eclass-overrides in
> ZM> /etc/portage/repos.conf, as documented in `man po
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 the
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
> "ZM" == Zac Medico writes:
ZM> On 04/06/2010 07:22 AM, James Cloos wrote:
>>> "ZM" == Zac Medico 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 u
On 04/06/2010 07:22 AM, James Cloos wrote:
>> "ZM" == Zac Medico 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 #27626
> "ZM" == Zac Medico 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 not con
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
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 exampl
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,
> "TV" == Torsten Veller 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 that every
On Tue, Mar 30, 2010 at 4:11 AM, Torsten Veller 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 functions.
>
23 matches
Mail list logo
