| 1 |
On Sun, Oct 27, 2013 at 8:03 AM, hasufell <hasufell@g.o> wrote: |
| 2 |
> -----BEGIN PGP SIGNED MESSAGE----- |
| 3 |
> Hash: SHA1 |
| 4 |
> |
| 5 |
> On 10/27/2013 02:30 AM, Mike Gilbert wrote: |
| 6 |
>> |
| 7 |
>> The (non-)relationship between eselect python and PYTHON_TARGETS |
| 8 |
>> is something that would be nice to resolve, but I don't know how to |
| 9 |
>> do it. PYTHON_SINGLE_TARGET will probably cause problems if/when |
| 10 |
>> packages start supporting python3 only. |
| 11 |
>> |
| 12 |
> |
| 13 |
> I think python-single-r1 is one of the major problems for users, |
| 14 |
> because they have to mess with two variables/useflags. Most just put |
| 15 |
> PYTHON_SINGLE_TARGET="python3_3" or something in make.conf which then |
| 16 |
> again affects all packages and WILL cause blockers/unresolvable deps. |
| 17 |
> |
| 18 |
> Afair in the very early versions we just picked the "best" |
| 19 |
> implementation and were done with it (since a python-single-r1 package |
| 20 |
> should not provide modules anyway). |
| 21 |
> |
| 22 |
> What is wrong with that approach (except that it still causes useless |
| 23 |
> rebuilds)? Do users really need that sort of control over non-module |
| 24 |
> packages? If they really do, you can still do some additional work and |
| 25 |
> make a real python-r1 package out of it. |
| 26 |
|
| 27 |
I guess the obvious downside to doing that would be extraneous |
| 28 |
dependencies. You would end up with packages that are installed for |
| 29 |
only one version of python, but "depend" on libraries for every |
| 30 |
version of python in PYTHON_TARGETS. That's probably not a big deal. |
| 31 |
|
| 32 |
However, you could potentially have a *library* that supports only a |
| 33 |
single version of python and uses python-single-r1; in that case we |
| 34 |
absolutely must know for which version of python it was installed to |
| 35 |
allow other python-single-r1 packages to depend on it correctly. |
Archives