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". I have already committed Arfrever's patch. If anyone wants to move the dependency into the ebuilds, you are welcome to do so; patching the eclass was just faster/easier.
