| 1 |
On Sun, 9 Apr 2017 12:15:56 -0400 |
| 2 |
"William L. Thomson Jr." <wlt-ml@××××××.com> wrote: |
| 3 |
|
| 4 |
> |
| 5 |
> The approach mentioned above, if the packages do not have issue. I |
| 6 |
> could go ahead and switch to ruby24 and pyton 3.6 across the board. |
| 7 |
> Which I cannot do now till a bunch of ebulids have their targets |
| 8 |
> increased. |
| 9 |
> |
| 10 |
|
| 11 |
This could introduce tree breakage. |
| 12 |
|
| 13 |
Why? |
| 14 |
|
| 15 |
Because of the whole |
| 16 |
|
| 17 |
"X built with python FOO depends on a Y built with python FOO" mechanic. |
| 18 |
|
| 19 |
As it stands, when unmasking a new python, people have to go through and mark |
| 20 |
packages as working, which has the requirement that their dependencies are themselves working |
| 21 |
in order to satisfy the USE requirements. |
| 22 |
|
| 23 |
When you reverse this, you introduce a situation where adding a new version across the board |
| 24 |
creates a new skeleton-tree of support. |
| 25 |
|
| 26 |
And when you find something that *doesnt* work, you may have to recursively |
| 27 |
mark its *dependents* as "non-working" to avoid a dependency graph breakage. |
| 28 |
|
| 29 |
This is the sort of thing that makes life hell, for both developers |
| 30 |
and users. |
| 31 |
|
| 32 |
I could be barking up the wrong tree, buy the python team could give a |
| 33 |
better idea of what that would look like in practice than me. |
| 34 |
|
| 35 |
But I fear this would look like "the hell of dekeywording" made harder |
| 36 |
by the lack of tools to facilitate such a thing. |
Archives