1 |
EAPI in profiles and the -live version suffix are some of the improvements |
2 |
many people would like to see in the tree. Unfortunately, the risk of breaking |
3 |
systems with old versions of portage has been too high, holding evolution |
4 |
back. |
5 |
|
6 |
I've been thinking about a way to solve this that would be easy to implement, |
7 |
without any significant compromises and one thing comes to mind: |
8 |
|
9 |
Manipulation of the SYNC variable (i.e. rsync module), |
10 |
combined with tree snapshots. |
11 |
|
12 |
At the moment, all systems have a SYNC line similar to this: |
13 |
|
14 |
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" |
15 |
|
16 |
My idea is simple. When incompatible changes have to be introduced to the |
17 |
tree, push a new version of portage that includes support for all the new |
18 |
features we want to provide. |
19 |
|
20 |
Then, freeze the tree and clone it into a revbumped rsync module, i.e. |
21 |
|
22 |
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage-r1" |
23 |
|
24 |
That way the last update provided by the old tree will be the updated portage |
25 |
package, which will be aware of the SYNC change. |
26 |
|
27 |
After the user installs that update, every subsequent emerge run will print a |
28 |
fat red warning telling the user that the tree has been revbumped. |
29 |
|
30 |
It will then provide instructions on how to update the make.conf/SYNC |
31 |
and a Y/N prompt to fix it itself. It could even do it automatically, |
32 |
but that's debatable. |
33 |
|
34 |
By doing this we can be sure that any user using the revbumped SYNC have |
35 |
an up-to-date portage (if they cheated, well, that's their problem), allowing |
36 |
us to use all the new features provided by the latest version of portage. |
37 |
|
38 |
For the above to work, we would require at least |
39 |
- support for multiple rsync modules pointing to different trees |
40 |
[also in mirrors] |
41 |
- a way to freeze the current state of the tree for the current rsync module |
42 |
and push future updates to a revbumped rsync module. |
43 |
- update our portage-snapshot tools to use the latest rsync module. |
44 |
- other things I'm probably forgetting right now |
45 |
|
46 |
I'm not sure how much work would be required to make our current |
47 |
infrastructure support this, the infra people could shed some light on |
48 |
this. |
49 |
|
50 |
The idea is to use this system sparingly, only when we need to push big |
51 |
changes that can't be supplied through an EAPI. Another example would be a |
52 |
change that would break the upgrade path. By freezing the tree at the right |
53 |
moment, we can be sure that the users will follow a known upgrade path |
54 |
that works. |
55 |
|
56 |
Please keep in mind that my solution isn't trying to be the best thing |
57 |
possible. Instead, I'm aiming for something that would do the job and would be |
58 |
implemented in a realistic timeframe. |
59 |
|
60 |
What do you guys think? |
61 |
-- |
62 |
Alex Alexander | wired |
63 |
+ Gentoo Linux Developer |
64 |
++ www.linuxized.com |