List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Tue, 28 Jun 2011 10:04:58 +0200
Dirkjan Ochtman <email@example.com> wrote:
> On Mon, Jun 27, 2011 at 21:31, Michał Górny <firstname.lastname@example.org> wrote:
> > Working targets. USE_PYTHON is junk. What python.eclass does now
> > with ABIs is a PITA, and requires manually providing a lot of
> > redudant information (namely, RESTRICT_PYTHON_ABIS).
> Please clarify *why* it is a PITA, and what information is redundant.
Let's put it like that. I have package foo which support py2 and py3.
It depends on package bar which once supported py3 but the newest
version is known to be broken with py3, and thus breaks building my
package as well.
And right now there's no real way to handle that dependency. With
SLOT-USEdeps I could do 'bar[py3=]'. With current state of Python
eclass I have to restrict ABIs to match newer version and/or restrict
dependency versions which is awfully redundant.
> > I'd like to see that fixed somehow. I'd like to set a single
> > supported Python version information in an ebuild, and let the
> > dependency resolver handle everything else.
> That would be bad; it's common and useful to have packages installed
> in both 2.6 and 2.7 (and even 3.1).
I think you misunderstood me. I mean generating the whole dependency
tree from support Python versions. Like dropping version info from
PYTHON_DEPEND in favor of RESTRICT_PYTHON_ABIS.