From: Mike Gilbert <floppym@gentoo.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] did python-r1 improve user experience?
Date: Sat, 26 Oct 2013 22:48:11 -0400 [thread overview]
Message-ID: <CAJ0EP42OF_bHoaSPVzBWysxW6Mp3Wp=FQAOXe7fiSrNAGSk8bQ@mail.gmail.com> (raw)
In-Reply-To: <20131027021810.GA15388@waltdnes.org>
On Sat, Oct 26, 2013 at 10:18 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Sat, Oct 26, 2013 at 09:30:57PM -0400, Mike Gilbert wrote
>
>> The (non-)relationship between eselect python and PYTHON_TARGETS is
>> something that would be nice to resolve, but I don't know how to do
>> it. PYTHON_SINGLE_TARGET will probably cause problems if/when packages
>> start supporting python3 only.
>
> What I find interesting/annoying is that my make.conf has to have 3
> lines...
>
> PYTHON_SINGLE_TARGET="python2_7"
> PYTHON_TARGETS="python2_7"
> USE_PYTHON="2.7"
>
> ...as if it didn't hear me the first time. How difficult would it be to
> set up an eclass to tell portage that...
>
> if PYTHON_SINGLE_TARGET="pythonX_Y"
>
> PYTHON_TARGETS defaults to "${PYTHON_SINGLE_TARGET}"
>
> USE_PYTHON defaults to "${PYTHON_SINGLE_TARGET/_/.}"
>
> Over-ride the default if explicitly listed. Out of sheer curiousity,
> what circumstances are there where ordinary users would need differing
> values for these 3 items?
>
PYTHON_TARGETS and PYTHON_SINGLE_TARGET are used indirectly by
python-r1.eclass. However, both are both expanded into use flags and
used in dependency calculations before any ebuild/eclass code is
invoked. So, we cannot manipulate them in an eclass or ebuild.
PYTHON_TARGETS may contain multiple python versions and is used for
most python packages in the tree. It allows the same package to be
installed for multiple python versions simultaneously.
PYTHON_SINGLE_TARGET should only contain one python version; it is
used for packages which cannot (easily) be made to support multiple
versions of python simultaneously. So we have to pick one.
USE_PYTHON is a legacy setting used by the old python.eclass and is
not used to control any use flags or dependencies. Ideally, we could
default this to PYTHON_TARGETS, but due to the way use-expanded
variables work this is not possible. This variable will go away once
python.eclass is removed from the portage tree.
next prev parent reply other threads:[~2013-10-27 2:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-23 13:13 [gentoo-user] did python-r1 improve user experience? hasufell
2013-10-27 1:30 ` Mike Gilbert
2013-10-27 2:18 ` Walter Dnes
2013-10-27 2:22 ` Bruce Hill
2013-10-27 2:48 ` Mike Gilbert [this message]
2013-10-27 3:41 ` William Kenworthy
2013-10-27 19:53 ` Mike Gilbert
2013-11-01 2:11 ` gottlieb
2013-11-01 13:41 ` gottlieb
2013-11-01 14:01 ` Alan McKinnon
2013-11-01 15:43 ` gottlieb
2013-11-01 20:17 ` Alan McKinnon
2013-11-01 21:56 ` gottlieb
2013-11-02 1:22 ` Alan McKinnon
2013-11-01 20:30 ` Bruce Hill
2013-10-27 12:03 ` hasufell
2013-10-27 19:43 ` Mike Gilbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJ0EP42OF_bHoaSPVzBWysxW6Mp3Wp=FQAOXe7fiSrNAGSk8bQ@mail.gmail.com' \
--to=floppym@gentoo.org \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox