19.08.2014 00:23, hasufell пишет:
> Chris Reffett:
>>
>>
>> On August 18, 2014 11:11:56 AM EDT, "Michał Górny" wrote:
>>> Dnia 2014-08-18, o godz. 09:22:46
>>> Chris Reffett napisał(a):
>>>
On 8/18/2014 8:56 AM, hasufell wrote:
> Almost forgot, of course this does not work if you expect
18.08.2014 16:56, hasufell пишет:
> hasufell:
>>
>> Even more interesting... you can work around this by inheriting
>> base.eclass explicitly before e.g. unpacker.eclass, something like
>>
>> inherit base unpacker games
>>
>> => unpacker_src_unpack() is carried out by default (and the ebuild
>> bre
Chris Reffett:
>
>
> On August 18, 2014 11:11:56 AM EDT, "Michał Górny" wrote:
>> Dnia 2014-08-18, o godz. 09:22:46
>> Chris Reffett napisał(a):
>>
>>> On 8/18/2014 8:56 AM, hasufell wrote:
Almost forgot, of course this does not work if you expect
unpacker_src_unpacker() to run:
Dnia 2014-08-18, o godz. 15:37:26
Chris Reffett napisał(a):
>
>
> On August 18, 2014 11:11:56 AM EDT, "Michał Górny" wrote:
> >Dnia 2014-08-18, o godz. 09:22:46
> >Chris Reffett napisał(a):
> >
> >> On 8/18/2014 8:56 AM, hasufell wrote:
> >> > Almost forgot, of course this does not work if yo
On August 18, 2014 11:11:56 AM EDT, "Michał Górny" wrote:
>Dnia 2014-08-18, o godz. 09:22:46
>Chris Reffett napisał(a):
>
>> On 8/18/2014 8:56 AM, hasufell wrote:
>> > Almost forgot, of course this does not work if you expect
>> > unpacker_src_unpacker() to run:
>> > inherit unpacker games base
Dnia 2014-08-18, o godz. 09:22:46
Chris Reffett napisał(a):
> On 8/18/2014 8:56 AM, hasufell wrote:
> > Almost forgot, of course this does not work if you expect
> > unpacker_src_unpacker() to run:
> > inherit unpacker games base
> >
> > as well as
> > inherit unpacker base games
> >
> > howeve
On Mon, Aug 18, 2014 at 8:56 AM, hasufell wrote:
>
> So in the end 3 eclasses all tell you "inherit me last! really!". Good
> luck with figuring out how to make a gnome game with python and multilib
> support work together. I can predict the days such a review would take
> in #gentoo-sunrise. Not
Chris Reffett:
> On 8/18/2014 8:56 AM, hasufell wrote:
>> hasufell:
>>>
>>> Even more interesting... you can work around this by inheriting
>>> base.eclass explicitly before e.g. unpacker.eclass, something like
>>>
>>> inherit base unpacker games
>>>
>>> => unpacker_src_unpack() is carried out by d
On Mon, Aug 18, 2014 at 8:21 AM, Sergey Popov wrote:
> 18.08.2014 14:44, Rich Freeman пишет:
>> On Mon, Aug 18, 2014 at 4:54 AM, Sergey Popov wrote:
>>> 17.08.2014 01:54, William Hubbs пишет:
# Foo and bar both have src_unpack and src_install functions.
# we want foo's src_unpack a
On 8/18/2014 8:56 AM, hasufell wrote:
> hasufell:
>>
>> Even more interesting... you can work around this by inheriting
>> base.eclass explicitly before e.g. unpacker.eclass, something like
>>
>> inherit base unpacker games
>>
>> => unpacker_src_unpack() is carried out by default (and the ebuild
>>
hasufell:
>
> Even more interesting... you can work around this by inheriting
> base.eclass explicitly before e.g. unpacker.eclass, something like
>
> inherit base unpacker games
>
> => unpacker_src_unpack() is carried out by default (and the ebuild
> breaks if someone thinks the base.eclass is
Dnia 2014-08-18, o godz. 12:41:11
hasufell napisał(a):
> hasufell:
> > Sergey Popov:
> >> 18.08.2014 16:04, hasufell пишет:
> You have my strong opposition on such change as well. It will turn
> ebuilds into unreadable and undpredictable mess, please do not do that
>
> >>>
> >>> Th
hasufell:
> Sergey Popov:
>> 18.08.2014 16:04, hasufell пишет:
You have my strong opposition on such change as well. It will turn
ebuilds into unreadable and undpredictable mess, please do not do that
>>>
>>> They are already fairly unreadable and unpredictable.
>>>
>>
>> For you - m
Sergey Popov:
> 18.08.2014 16:04, hasufell пишет:
>>> You have my strong opposition on such change as well. It will turn
>>> ebuilds into unreadable and undpredictable mess, please do not do that
>>>
>>
>> They are already fairly unreadable and unpredictable.
>>
>
> For you - maybe. But not for me
18.08.2014 14:44, Rich Freeman пишет:
> On Mon, Aug 18, 2014 at 4:54 AM, Sergey Popov wrote:
>> 17.08.2014 01:54, William Hubbs пишет:
>>>
>>> # Foo and bar both have src_unpack and src_install functions.
>>> # we want foo's src_unpack and bar's src_install:
>>>
>>> ECLASS_PHASES="foo_src_unpack
>
18.08.2014 16:04, hasufell пишет:
>> You have my strong opposition on such change as well. It will turn
>> ebuilds into unreadable and undpredictable mess, please do not do that
>>
>
> They are already fairly unreadable and unpredictable.
>
For you - maybe. But not for me.
I am NOT talking abou
Sergey Popov:
>
> You have my strong opposition on such change as well. It will turn
> ebuilds into unreadable and undpredictable mess, please do not do that
>
They are already fairly unreadable and unpredictable.
On Mon, Aug 18, 2014 at 4:54 AM, Sergey Popov wrote:
> 17.08.2014 01:54, William Hubbs пишет:
>>
>> # Foo and bar both have src_unpack and src_install functions.
>> # we want foo's src_unpack and bar's src_install:
>>
>> ECLASS_PHASES="foo_src_unpack
>> bar_src_install"
>
> You have my stron
17.08.2014 01:54, William Hubbs пишет:
> All,
>
> there is an ongoing discussion about how we handle eclass phase
> functions by default [1].
>
> Currently, EXPORT_FUNCTIONS is called in eclasses, and because of the
> way this works, the phase function that is exported last in the chain of
> inhe
On Sun, Aug 17, 2014 at 2:54 AM, Ulrich Mueller wrote:
>> On Sat, 16 Aug 2014, William Hubbs wrote:
>
>> My counter proposal to this is that we stop calling eclass phase
>> functions automatically, and to minimize the amount of boilerplating
>> we would have to do, we use a variable, such as E
On 17 August 2014 19:03, Michał Górny wrote:
>
> > So if you could sculpt it to be broader by default and have less scope
> for
> > developer error, that'd be an improvement.
> >
> > --- code start --
> > ECLASS_EXCLUDE="foo_src_unpack bar_src_unpack"
> > inherit foo bar baz
> >
> >
> > --- code
On 8/17/14, 9:18 AM, Michał Górny wrote:
> Dnia 2014-08-17, o godz. 09:06:04
> "Paweł Hajdan, Jr." napisał(a):
>> The warning would make the problem more visible to ebuild writers. Then
>> we already have a solution that works, i.e. explicitly defining the
>> phase function in the ebuild, possibly
Dnia 2014-08-17, o godz. 09:06:04
"Paweł Hajdan, Jr." napisał(a):
> On 8/17/14, 12:32 AM, Kent Fredric wrote:
> > Collison systems I've seen usually do one of two things:
> >
> > - In the event of a collision, demand the consumer resolve the problem by
> > redefining the function the collision o
On 8/17/14, 12:32 AM, Kent Fredric wrote:
> Collison systems I've seen usually do one of two things:
>
> - In the event of a collision, demand the consumer resolve the problem by
> redefining the function the collision occurs on in terms of its composite
> parts. ( which is basically what we alrea
Dnia 2014-08-17, o godz. 10:32:14
Kent Fredric napisał(a):
> So if you could sculpt it to be broader by default and have less scope for
> developer error, that'd be an improvement.
>
> --- code start --
> ECLASS_EXCLUDE="foo_src_unpack bar_src_unpack"
> inherit foo bar baz
>
>
> --- code end -
> On Sat, 16 Aug 2014, William Hubbs wrote:
> The initial proposal is to change this behaviour so that the PMS
> default phase functions call all matching phase functions from
> inherited eclasses in sequence.
> I strongly oppose this change, because I feel it will make our
> entire tree very
On Sun, Aug 17, 2014 at 12:54:17AM +0200, Michał Górny wrote:
> Dnia 2014-08-16, o godz. 16:54:28
> William Hubbs napisał(a):
>
> > The initial proposal is to change this behaviour so that the PMS default
> > phase functions call all matching phase functions from inherited
> > eclasses in sequenc
On Sun, Aug 17, 2014 at 10:32:14AM +1200, Kent Fredric wrote:
> On 17 August 2014 09:54, William Hubbs wrote:
> > My counter proposal to this is that we stop calling eclass phase
> > functions automatically, and to minimize the amount of boilerplating
> > we would have to do, we use a variable,
Dnia 2014-08-16, o godz. 16:54:28
William Hubbs napisał(a):
> The initial proposal is to change this behaviour so that the PMS default
> phase functions call all matching phase functions from inherited
> eclasses in sequence.
>
> For example:
>
> - your ebuild inherits foo and bar and each of t
On 17 August 2014 09:54, William Hubbs wrote:
> I strongly oppose this change, because I feel it will make our
> entire tree very unpredictable at best. I realize this might eliminate
> boilerplating from our tree. Weighing that against the possible
> ramifications in this big of a change in auto
All,
there is an ongoing discussion about how we handle eclass phase
functions by default [1].
Currently, EXPORT_FUNCTIONS is called in eclasses, and because of the
way this works, the phase function that is exported last in the chain of
inherited eclasses is the one that is called for a given ph
31 matches
Mail list logo
