public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Mike Gilbert <floppym@gentoo.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] did python-r1 improve user experience?
Date: Sun, 27 Oct 2013 15:43:29 -0400	[thread overview]
Message-ID: <CAJ0EP41iqUOh1Uepr8FAGRwtj4jQq_4GKQ6_1LjwLhEBcJA+bA@mail.gmail.com> (raw)
In-Reply-To: <526D010A.1030307@gentoo.org>

On Sun, Oct 27, 2013 at 8:03 AM, hasufell <hasufell@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/27/2013 02:30 AM, 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.
>>
>
> I think python-single-r1 is one of the major problems for users,
> because they have to mess with two variables/useflags. Most just put
> PYTHON_SINGLE_TARGET="python3_3" or something in make.conf which then
> again affects all packages and WILL cause blockers/unresolvable deps.
>
> Afair in the very early versions we just picked the "best"
> implementation and were done with it (since a python-single-r1 package
> should not provide modules anyway).
>
> What is wrong with that approach (except that it still causes useless
> rebuilds)? Do users really need that sort of control over non-module
> packages? If they really do, you can still do some additional work and
> make a real python-r1 package out of it.

I guess the obvious downside to doing that would be extraneous
dependencies. You would end up with packages that are installed for
only one version of python, but "depend" on libraries for every
version of python in PYTHON_TARGETS. That's probably not a big deal.

However, you could potentially have a *library* that supports only a
single version of python and uses python-single-r1; in that case we
absolutely must know for which version of python it was installed to
allow other python-single-r1 packages to depend on it correctly.


      reply	other threads:[~2013-10-27 19:43 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
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 [this message]

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=CAJ0EP41iqUOh1Uepr8FAGRwtj4jQq_4GKQ6_1LjwLhEBcJA+bA@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