| 1 |
On Thu, 12 Sep 2013 10:49:00 +0200 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
> Hello, |
| 5 |
> |
| 6 |
> However, the upgrade itself seems harder to accomplish. Specifically, |
| 7 |
> all the simple ways of achieving that would involve changing stable |
| 8 |
> packages. |
| 9 |
> |
| 10 |
> So far, I can think of three solutions, starting with the worst: |
| 11 |
> |
| 12 |
> 1. Deploy the new stuff in an overlay (except for python-exec:2 |
| 13 |
> itself), keep it there for some time asking people to test with |
| 14 |
> eclasses overriding the main tree. Then ask arch teams to stabilize |
| 15 |
> python-exec:2. When it hits stable, move the changes to the tree. |
| 16 |
> |
| 17 |
> 2. Make the new features controlled via make.conf variable. Ask users |
| 18 |
> to test with it enabled, then file a stablereq for arch teams to test |
| 19 |
> with the switch enabled, plus stabilize the few packages which will |
| 20 |
> need direct changes. Then remove the switch and make the new behavior |
| 21 |
> default for all stuff. |
| 22 |
> |
| 23 |
> 3. python-r2, python-single-r2, distutils-r2 :). |
| 24 |
> |
| 25 |
> |
| 26 |
> Anyone has a better idea? |
| 27 |
> |
| 28 |
|
| 29 |
You could make sure that python-exec:2 is marked ~arch and in the |
| 30 |
eclass check the version installed and switch according to that. For |
| 31 |
stable users everything will stay the same, and for ~arch users all new |
| 32 |
installs/upgrades will be switched to the new system. This will even |
| 33 |
work if we want to mask it for a bit, so developers can test before |
| 34 |
letting it into ~arch. |
Archives