| 1 |
On 2018-12-10 11:07 a.m., Michał Górny wrote: |
| 2 |
> What can we do to solve it? |
| 3 |
> =========================== |
| 4 |
> |
| 5 |
> a) Do nothing and hope upstreams solve it at some point. I don't think |
| 6 |
> this is acceptable because Portage's slowdown is going to be |
| 7 |
> significant. |
| 8 |
> |
| 9 |
> b) Start dropping py2 from packages. Sadly, this is hard because we're |
| 10 |
> talking about huge reverse dependency graph, and I'm pretty sure some of |
| 11 |
> our users need those packages w/ py2 support. |
| 12 |
> |
| 13 |
> c) Slot IPython? That's probably the least intrusive option, though |
| 14 |
> ugly as hell, and I'm not sure if it's not going to impact dep |
| 15 |
> calculation severely anyway. We'd have a :5 slot that supports py2 |
| 16 |
> only, and :0 slot that supports py3 only. Dependencies will be tricky, |
| 17 |
> life's going to be hard but maybe things will work. |
| 18 |
> |
| 19 |
> Any other options? |
| 20 |
|
| 21 |
This'll be uglier for maintainers but cleaner for the repo -- what |
| 22 |
about a single IPython "package" that installs :5 for py2 and :0 for |
| 23 |
py3 ? Since python multi-builds anyways it shouldn't be too difficult |
| 24 |
to have it install from separate distfiles. Versioning would be a |
| 25 |
royal pain, likely some sort of combination of versions into a |
| 26 |
snapshot version number of sorts would need to be done... |
Archives