| 1 |
Hello! |
| 2 |
|
| 3 |
|
| 4 |
I have done a bit more testing now. To do so I have isolated the |
| 5 |
eselect-python-update behavior into testing ebuilds (package |
| 6 |
"virtual/debug-eselect-python") reduced to just that problem (no |
| 7 |
compilation and the like, see attachment, also in sping overlay). |
| 8 |
|
| 9 |
The test scenario is made of two halves: one half is an ebuild running |
| 10 |
eselect python update on pkg_postrm (the 2.7 one, to emulate what users |
| 11 |
may have still installed), the other is an ebuild with the |
| 12 |
work-in-progress patch I plan to apply to dev-lang/python instrumented |
| 13 |
with debugging output (the 2.7.1 one). |
| 14 |
|
| 15 |
|
| 16 |
To recall, the goal is: |
| 17 |
|
| 18 |
1) Having valid symlinks for /usr/bin/python |
| 19 |
|
| 20 |
2) Keeping active Python versions untouched, i.e. reverting a change |
| 21 |
by an ebuild calling eselect-python-update during pkg_postrm. |
| 22 |
|
| 23 |
|
| 24 |
The test scenario is these three commands on a root shell: |
| 25 |
|
| 26 |
# EMERGE_DEFAULT_OPTS= emerge -1av =virtual/debug-eselect-python-2.7 |
| 27 |
# eselect python set python2.6 |
| 28 |
# EMERGE_DEFAULT_OPTS= emerge -1av =virtual/debug-eselect-python-2.7.1 |
| 29 |
|
| 30 |
The output of the third call is the interesting part, see attachment. |
| 31 |
Besides my earlier mixup of |
| 32 |
|
| 33 |
eselect python set --pythonX pythonX.Y # good |
| 34 |
|
| 35 |
with |
| 36 |
|
| 37 |
eselect python set pythonX.Y --pythonX # bad |
| 38 |
|
| 39 |
the patch proposed earlier seems to be a promising approach. |
| 40 |
|
| 41 |
Next I will apply this appraoch to dev-lang/python int the main tree. |
| 42 |
I expect that to take no longer than two hours, hopefully less. |
| 43 |
|
| 44 |
If you spot any practical problems with this please mail me ASAP. |
| 45 |
|
| 46 |
Wish me luck so I don't break anything for worse. |
| 47 |
|
| 48 |
Best, |
| 49 |
|
| 50 |
|
| 51 |
|
| 52 |
Sebastian |
Archives