Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Cc: djc@g.o
Subject: Re: [gentoo-dev] The Python problem
Date: Tue, 28 Jun 2011 08:21:31
Message-Id: 20110628102122.6b403837@pomiocik.lan
In Reply to: Re: [gentoo-dev] The Python problem by Dirkjan Ochtman
On Tue, 28 Jun 2011 10:04:58 +0200
Dirkjan Ochtman <djc@g.o> wrote:

> On Mon, Jun 27, 2011 at 21:31, Michał Górny <mgorny@g.o> 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. -- Best regards, Michał Górny


File name MIME type
signature.asc application/pgp-signature