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
breaks if someone
19.08.2014 00:23, hasufell пишет:
Chris Reffett:
On August 18, 2014 11:11:56 AM EDT, Michał Górny mgo...@gentoo.org wrote:
Dnia 2014-08-18, o godz. 09:22:46
Chris Reffett creff...@gentoo.org napisał(a):
On 8/18/2014 8:56 AM, hasufell wrote:
Almost forgot, of course this does not work if
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
inherited
On Mon, Aug 18, 2014 at 4:54 AM, Sergey Popov pinkb...@gentoo.org 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
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.
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 about hacks
18.08.2014 14:44, Rich Freeman пишет:
On Mon, Aug 18, 2014 at 4:54 AM, Sergey Popov pinkb...@gentoo.org 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
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.
I am NOT
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 - maybe. But not for me.
I
Dnia 2014-08-18, o godz. 12:41:11
hasufell hasuf...@gentoo.org 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
They are
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 useless
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
breaks if
On Mon, Aug 18, 2014 at 8:21 AM, Sergey Popov pinkb...@gentoo.org wrote:
18.08.2014 14:44, Rich Freeman пишет:
On Mon, Aug 18, 2014 at 4:54 AM, Sergey Popov pinkb...@gentoo.org wrote:
17.08.2014 01:54, William Hubbs пишет:
# Foo and bar both have src_unpack and src_install functions.
# we
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 default (and the ebuild
Dnia 2014-08-18, o godz. 09:22:46
Chris Reffett creff...@gentoo.org 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
On August 18, 2014 11:11:56 AM EDT, Michał Górny mgo...@gentoo.org wrote:
Dnia 2014-08-18, o godz. 09:22:46
Chris Reffett creff...@gentoo.org 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 creff...@gentoo.org napisał(a):
On August 18, 2014 11:11:56 AM EDT, Michał Górny mgo...@gentoo.org wrote:
Dnia 2014-08-18, o godz. 09:22:46
Chris Reffett creff...@gentoo.org napisał(a):
On 8/18/2014 8:56 AM, hasufell wrote:
Almost
Chris Reffett:
On August 18, 2014 11:11:56 AM EDT, Michał Górny mgo...@gentoo.org wrote:
Dnia 2014-08-18, o godz. 09:22:46
Chris Reffett creff...@gentoo.org napisał(a):
On 8/18/2014 8:56 AM, hasufell wrote:
Almost forgot, of course this does not work if you expect
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
Dnia 2014-08-17, o godz. 10:32:14
Kent Fredric kentfred...@gmail.com 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
---
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 already
Dnia 2014-08-17, o godz. 09:06:04
Paweł Hajdan, Jr. phajdan...@gentoo.org 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
On 8/17/14, 9:18 AM, Michał Górny wrote:
Dnia 2014-08-17, o godz. 09:06:04
Paweł Hajdan, Jr. phajdan...@gentoo.org 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
On 17 August 2014 19:03, Michał Górny mgo...@gentoo.org 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 end
On Sun, Aug 17, 2014 at 2:54 AM, Ulrich Mueller u...@gentoo.org 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
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
On 17 August 2014 09:54, William Hubbs willi...@gentoo.org 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
Dnia 2014-08-16, o godz. 16:54:28
William Hubbs willi...@gentoo.org 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
On Sun, Aug 17, 2014 at 10:32:14AM +1200, Kent Fredric wrote:
On 17 August 2014 09:54, William Hubbs willi...@gentoo.org 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
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 willi...@gentoo.org 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
30 matches
Mail list logo
