1 |
Dear Fellows, |
2 |
|
3 |
I am revisiting this topic based on previous discussions[1,2,3]. |
4 |
|
5 |
There seems to be a constant need for toolchain with a new EAPI. The |
6 |
only block is "how can we upgrade from an ancient system?", "don't bump |
7 |
or the upgrade path will be break". Let's figure out a solid upgrade |
8 |
path consciously, with a test farm of ancient systems, and then bump the |
9 |
EAPI of toolchain. |
10 |
|
11 |
Besides the upgrading guide[4] suggesting a chroot, rich0 had some |
12 |
experiences with a live overwriting of latest stage3 to /, recently I've |
13 |
heard from patrick of a script to bootstrap Gentoo lively on an existing |
14 |
system (be it Debian, Red Hat or an ancient Gentoo). |
15 |
|
16 |
Here is another alternative from Prefix (upgrading the kernel is mostly |
17 |
independent): |
18 |
|
19 |
a. we distribute a stage3 of Gentoo RAP(i.e. Prefix with libc), with |
20 |
EPREFIX pointing to, say, /tmp/upgrade |
21 |
b. sync the potage tree in the host system, switch it to the newest |
22 |
profile. |
23 |
c. PORTAGE_OVERRIDE_EPREFIX=/ /tmp/upgrade/usr/bin/emerge -e world |
24 |
|
25 |
It has the same solidity as the chroot while being easier without the |
26 |
need to mount back and forth. It can track installed files properly as |
27 |
opposed to overwriting /. |
28 |
|
29 |
This needs a lot of work to do the testing. At the same time, there are |
30 |
definitely a dozen of developers who want to bump the EAPI of |
31 |
toolchain. Let's share the workload. |
32 |
|
33 |
|
34 |
vapier, if we can figure out a solid and easy solution for upgrading |
35 |
ancient Gentoo, would you agree on bumping the EAPI of toolchain? |
36 |
|
37 |
|
38 |
Cheers, |
39 |
Benda |
40 |
|
41 |
1. http://thread.gmane.org/gmane.linux.gentoo.devel/86803 |
42 |
2. http://article.gmane.org/gmane.linux.gentoo.devel/73767 |
43 |
3. http://article.gmane.org/gmane.linux.gentoo.project/2841 |
44 |
4. http://www.gentoo.org/doc/en/gentoo-upgrading.xml |