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
12.08.2014 16:44, Jason Zaman пишет:
> On Tue, Aug 12, 2014 at 11:55:51AM +0400, Sergey Popov wrote:
>> 11.08.2014 04:25, Robin H. Johnson пишет:
>>> The attached list notes all of the packages that were added or removed
>>> from the tree, for the week ending 2014-08-10 23h59 UTC.
>>>
>>> Removals:
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
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.
William Hubbs:
> All,
>
> I spoke with mgorny on IRC and found out what his concerns are about our
> current eclasses.
>
> First, he thinks we should get rid of base.eclass.
>
> I know there is work going on to get rid of it, but I haven't really
> looked into the status much yet. I do agree tho
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
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
>
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
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
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:
>
> 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
On Mon, Aug 18, 2014 at 8:12 AM, hasufell wrote:
>
> I think the first thing to do and which already happened with e.g.
> qmake-utils.eclass is to make a very strong distinction between utility
> eclasses and those that export phase functions.
>
Discussion on IRC the other day was moving in this
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
>>
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
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 13 August 2014 02:46, Michał Górny wrote:
> Dnia 2014-08-11, o godz. 20:48:20
> William Hubbs napisał(a):
>> > got a minor (but chatty) QA warning:
>> > DESCRIPTION ends with a '.' character
>>
>> Why is this a QA warning in the first place?
>
> Because it is a common mistake, and having t
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
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 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. 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
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:
Hello,
Since most of EAPI6 seems to be defined already, I've started working
on an initial implementation for Portage. Since many of the features
are not precisely defined yet, I've made a few assumptions. I'd like
to ask you to look through it and ask any questions that may arise or
report any is
Hi all,
Last evening, the old sponsor where cvs/git/git.overlays was hosted
turned off the old servers, earlier than I expected.
With two notable exceptions listed below, almost everything should be
how it should be, so you can continue as before.
The new SSH keys, in case you still didn't have
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
24 matches
Mail list logo
