| 1 |
Hello, |
| 2 |
|
| 3 |
I need someone to confirm my thoughts. |
| 4 |
|
| 5 |
Packages built some time ago have 'dev-python/python-exec' (without any |
| 6 |
slot) in deps. This means that portage will be happy to remove |
| 7 |
python-exec:0 (and break those packages) as soon as python-exec:2 is |
| 8 |
installed. |
| 9 |
|
| 10 |
Modern Python packages have := dep on it. Those built with |
| 11 |
python-exec:2 around (and therefore using it) will have the dep |
| 12 |
converted to python-exec:2, and those with :0 will have :0. So those |
| 13 |
are fine. |
| 14 |
|
| 15 |
Now, we don't have a proper way of updating deps of the old packages, |
| 16 |
and portage's --dynamic-deps doesn't seem to handle it. We can either: |
| 17 |
|
| 18 |
a) tell users to hack their vdb and fix deps therein, |
| 19 |
|
| 20 |
b) tell users to rebuild all python stuff before running --depclean, |
| 21 |
|
| 22 |
c) move packages around a bit and possibly fix it. |
| 23 |
|
| 24 |
Since c) should work without requiring users to read news and hack or |
| 25 |
rebuild stuff, I think that'd be the best route. However, I'd need |
| 26 |
someone to confirm that my thoughts are correct. |
| 27 |
|
| 28 |
|
| 29 |
The idea would be to move python-exec2 to a separate package use that |
| 30 |
package in the eclass deps. That is: |
| 31 |
|
| 32 |
a) dev-python/python-exec2 would have two slots: |
| 33 |
|
| 34 |
- 2*:0 that would contain python-exec2 itself, |
| 35 |
|
| 36 |
- 0:compat that would pull in python-exec:0. |
| 37 |
|
| 38 |
b) dev-python/python-exec would have two slots: |
| 39 |
|
| 40 |
- 4.*:0 that would contain the original python-exec, |
| 41 |
|
| 42 |
- 3:2 that would pull in python-exec:2. |
| 43 |
|
| 44 |
c) the eclass would have the following dep: |
| 45 |
|
| 46 |
dev-python/python-exec2:= |
| 47 |
|
| 48 |
|
| 49 |
Now, I think the following would happen: |
| 50 |
|
| 51 |
a) 'dev-python/python-exec' deps would still be satisfied by any slot |
| 52 |
of python-exec but... |
| 53 |
|
| 54 |
b) @world upgrade will pull in highest PV with slot :0 for them, so |
| 55 |
they won't get broken, |
| 56 |
|
| 57 |
c) previously-built packages with 'python-exec:0' and |
| 58 |
'python-exec:2' (due to := dep) will still pull in correct version of |
| 59 |
python-exec (possibly through the compat version), |
| 60 |
|
| 61 |
d) new packages will have 'dev-python/python-exec2:=' dep and therefore |
| 62 |
use the new package. |
| 63 |
|
| 64 |
|
| 65 |
Notes: |
| 66 |
|
| 67 |
a) people who haven't installed python-exec:2 yet won't even use that |
| 68 |
slot, |
| 69 |
|
| 70 |
b) stable users will pull in python-exec2:compat virtual slot, |
| 71 |
|
| 72 |
c) when python-exec2:0 goes stable, people will cleanly upgrade to it, |
| 73 |
|
| 74 |
d) we will be able to lastrite dev-python/python-exec and remove |
| 75 |
dev-python/python-exec2:compat afterwards. In case people still use it, |
| 76 |
PM will simply keep the old versions in vardb, |
| 77 |
|
| 78 |
e) python-exec2:0 will have a blocker for <python-exec-3:2 to ensure |
| 79 |
clean switch. |
| 80 |
|
| 81 |
Am I missing something? |
| 82 |
|
| 83 |
-- |
| 84 |
Best regards, |
| 85 |
Michał Górny |
Archives