1 |
So I've tried now to upgrade in various ways: |
2 |
1. the one given in https://anongit.gentoo.org/git/repo/sync/gentoo.git |
3 |
But this fails as soon as I try to emerge git. python-exec is at version |
4 |
2.4.6 now. Without any 2.0.1 packed, legal versions left. Same for all |
5 |
other dependencies. Not really a way to go … |
6 |
|
7 |
2. I've tried downloading a recent stage3 file, unpack it, then go and |
8 |
upgrade from there. The recent stage3 file, I had to find out is, dating |
9 |
from 29th, September 2016, way outdated.It isn't even useful to compile |
10 |
anything. It will fail with any of the packages from portage as well. |
11 |
Upgrading portage-tree from there works, but – EAPI version mismatches make |
12 |
it impossible to compile anything. |
13 |
|
14 |
Since there isn't a stage3 and some portage tree matching, I'd ask: armv7 |
15 |
and others have gone unsupported? Just because nobody ever created a new |
16 |
stage3 file matching EAPI changes? |
17 |
|
18 |
On Wed, Dec 18, 2019 at 7:15 PM Rich Freeman <rich0@g.o> wrote: |
19 |
|
20 |
> On Wed, Dec 18, 2019 at 11:03 AM Grant Edwards |
21 |
> <grant.b.edwards@×××××.com> wrote: |
22 |
> > |
23 |
> > On 2019-12-18, <nunojsilva@×××××××.pt> (Nuno Silva) < |
24 |
> nunojsilva@×××××××.pt> wrote: |
25 |
> > |
26 |
> > > The EAPI problem is in a package that is pulled as a dependency of |
27 |
> > > portage. |
28 |
> > > |
29 |
> > > Unless there's a simple hack to solve this, you will need to use older |
30 |
> > > ebuilds or split the update in several steps, using older versions of |
31 |
> > > the portage tree. The following notes show a way of achieving this: |
32 |
> > > |
33 |
> > > https://wiki.gentoo.org/wiki/User:NeddySeagoon/HOWTO_Update_Old_Gentoo |
34 |
> > |
35 |
> > In my experience of situations like this, it's often a lot less work |
36 |
> > to just backup /etc and user home directories and re-install from |
37 |
> > scratch. |
38 |
> > |
39 |
> |
40 |
> That wiki article seems a bit dated, though it has the right general |
41 |
> concept. IMO it is way simpler than that. You could of course do a |
42 |
> reinstall and move your /etc and /home - that will certainly be the |
43 |
> cleanest approach. You'll probably clear out a lot of orphans or |
44 |
> things that are config-protected that have moved that way (well, less |
45 |
> so if you keep /etc whole). |
46 |
> |
47 |
> I think some of this hinges on just HOW old that system is. What was |
48 |
> the date that it was last updated on? |
49 |
> |
50 |
> Assuming it isn't older than 2015 I think the simplest safe approach |
51 |
> is to switch to a git repo, and then update it by date. |
52 |
> |
53 |
> You can use https://anongit.gentoo.org/git/repo/sync/gentoo.git as it |
54 |
> has the metadata cache included, but that didn't really start until |
55 |
> Aug 2018. Commits before that date won't include metadata, though you |
56 |
> can build that yourself. It also uses CI checks so in theory every |
57 |
> merge commit is clean and consistent. |
58 |
> |
59 |
> You can do date-based checkouts. I'd try jumping one year at a time |
60 |
> updating @system or at least portage+toolchain. If one of those |
61 |
> updates fails you can do a shorter update interval. |
62 |
> |
63 |
> You probably don't need to update @world until you get up to the |
64 |
> current date. As long as @system is updated it should be able to |
65 |
> bootstrap everything else. |
66 |
> |
67 |
> You can't just jump to the current portage as the current portage |
68 |
> ebuild is going to use an EAPI that isn't supported by the version of |
69 |
> portage you already have. Portage is usually updated in EAPI |
70 |
> conservatively to minimize this issue, but if you want to jump |
71 |
> multiple years at a time it won't work. Jumping 6-12mo at a time will |
72 |
> minimize this issue. |
73 |
> |
74 |
> -- |
75 |
> Rich |
76 |
> |
77 |
> |
78 |
|
79 |
-- |
80 |
Thomas |