| 1 |
On Wed, Oct 29, 2014 at 02:17:29PM -0400, Ian Stakenvicius wrote: |
| 2 |
> As python-single-r1.eclass is meant to ensure that a package is |
| 3 |
> bound to just one implementation when multiple implementations are |
| 4 |
> possible, usually because it is too difficult to make the package |
| 5 |
> multibuild, it would make sense to me that if there is actually just |
| 6 |
> one possible implementation… |
| 7 |
|
| 8 |
I understand “It's too difficult for me to get this build system to |
| 9 |
work with multiple Python versions.” I'm skeptical that there are any |
| 10 |
packages where “there is actually just one possible implementation.” |
| 11 |
Still I agree that some users will want a way to say “if I ask for a |
| 12 |
package that only installs for one Python implementation, just install |
| 13 |
it without my needing to tweak my USE flags.” |
| 14 |
|
| 15 |
Personally, I'd prefer to stick with my existing PYTHON_SINGLE_TARGET. |
| 16 |
If a package doesn't like that, I can think harder about whether or |
| 17 |
not I actually need the package. My Docker images [1], for example, |
| 18 |
are single-Python implementations and I don't want to pull in another |
| 19 |
Python accidentally. |
| 20 |
|
| 21 |
Cheers, |
| 22 |
Trevor |
| 23 |
|
| 24 |
[1]: https://github.com/wking/dockerfile |
| 25 |
|
| 26 |
-- |
| 27 |
This email may be signed or encrypted with GnuPG (http://www.gnupg.org). |
| 28 |
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy |
Archives