On Tue, Mar 20, 2012 at 5:20 PM, Alexis Ballier <aball...@gentoo.org> wrote:
> On Tue, 20 Mar 2012 17:09:55 -0400
> Mike Gilbert <flop...@gentoo.org> wrote:
>
>> On Tue, Mar 20, 2012 at 5:05 PM, Alexis Ballier <aball...@gentoo.org>
>> wrote:
>> > On Tue, 20 Mar 2012 17:57:29 -0300
>> > Alexis Ballier <aball...@gentoo.org> wrote:
>> >
>> >> On Tue, 20 Mar 2012 20:35:17 +0100
>> >> Arfrever Frehtes Taifersar Arahesis <arfre...@gentoo.org> wrote:
>> >>
>> >> > 2012-03-20 17:53:56 Michał Górny napisał(a):
>> >> > > On Tue, 20 Mar 2012 17:41:39 +0100
>> >> > > Arfrever Frehtes Taifersar Arahesis <arfre...@gentoo.org>
>> >> > > wrote:
>> >> > >
>> >> > > > 2012-03-20 05:29:20 Luca Barbato napisał(a):
>> >> > > > > Hi, I tried to avoid depending on eselect-python if the
>> >> > > > > useflag is disabled.
>> >> > > > >
>> >> > > > > Please test and review.
>> >> > > >
>> >> > > > The proper fix is to make python.eclass add dependency on
>> >> > > > app-admin/eselect-python only when ${CATEGORY}/${PN} is
>> >> > > > dev-lang/python, dev-java/jython or dev-python/pypy. See bug
>> >> > > > #341037.
>> >> > >
>> >> > > Couldn't we just push that dependency to the specific ebuilds?
>> >> >
>> >> > We want to control required version (>=20091230 in case of
>> >> > app-admin/eselect-python) in 1 place.
>> >> >
>> >>
>> >> this can be achieved by setting a variable that said ebuilds will
>> >> append to (R)DEPEND; no need for complex 'if then else' on CAT/PN
>> >> in an eclass for this.
>> >>
>> >
>> > or also by adding a new python-implementation.eclass instead of
>> > polluting an eclass used by hundreds of packages for only 3 special
>> > ones...
>> >
>>
>> A four-way if-then statement is not what I would call "complex". This
>> was already present in the eclass anyway, so there is no additional
>> "pollution".
>
> a four-way if-then with pattern matching / strcmp is slower than a
> constant variable assignment; it could matter when this is done
> everytime an ebuild inheriting it is sourced. it probably doesnt, but
> imho, its good practice to keep global scope code in eclasses as simple
> as possible.
>Ah right. It is now being executed in global scope, so there is a slight performance degradation there. Point taken.
