So I've tried now to upgrade in various ways: 1. the one given in https://anongit.gentoo.org/git/repo/sync/gentoo.git But this fails as soon as I try to emerge git. python-exec is at version 2.4.6 now. Without any 2.0.1 packed, legal versions left. Same for all other dependencies. Not really a way to go …
2. I've tried downloading a recent stage3 file, unpack it, then go and upgrade from there. The recent stage3 file, I had to find out is, dating from 29th, September 2016, way outdated.It isn't even useful to compile anything. It will fail with any of the packages from portage as well. Upgrading portage-tree from there works, but – EAPI version mismatches make it impossible to compile anything. Since there isn't a stage3 and some portage tree matching, I'd ask: armv7 and others have gone unsupported? Just because nobody ever created a new stage3 file matching EAPI changes? On Wed, Dec 18, 2019 at 7:15 PM Rich Freeman <ri...@gentoo.org> wrote: > On Wed, Dec 18, 2019 at 11:03 AM Grant Edwards > <grant.b.edwa...@gmail.com> wrote: > > > > On 2019-12-18, <nunojsi...@ist.utl.pt> (Nuno Silva) < > nunojsi...@ist.utl.pt> wrote: > > > > > The EAPI problem is in a package that is pulled as a dependency of > > > portage. > > > > > > Unless there's a simple hack to solve this, you will need to use older > > > ebuilds or split the update in several steps, using older versions of > > > the portage tree. The following notes show a way of achieving this: > > > > > > https://wiki.gentoo.org/wiki/User:NeddySeagoon/HOWTO_Update_Old_Gentoo > > > > In my experience of situations like this, it's often a lot less work > > to just backup /etc and user home directories and re-install from > > scratch. > > > > That wiki article seems a bit dated, though it has the right general > concept. IMO it is way simpler than that. You could of course do a > reinstall and move your /etc and /home - that will certainly be the > cleanest approach. You'll probably clear out a lot of orphans or > things that are config-protected that have moved that way (well, less > so if you keep /etc whole). > > I think some of this hinges on just HOW old that system is. What was > the date that it was last updated on? > > Assuming it isn't older than 2015 I think the simplest safe approach > is to switch to a git repo, and then update it by date. > > You can use https://anongit.gentoo.org/git/repo/sync/gentoo.git as it > has the metadata cache included, but that didn't really start until > Aug 2018. Commits before that date won't include metadata, though you > can build that yourself. It also uses CI checks so in theory every > merge commit is clean and consistent. > > You can do date-based checkouts. I'd try jumping one year at a time > updating @system or at least portage+toolchain. If one of those > updates fails you can do a shorter update interval. > > You probably don't need to update @world until you get up to the > current date. As long as @system is updated it should be able to > bootstrap everything else. > > You can't just jump to the current portage as the current portage > ebuild is going to use an EAPI that isn't supported by the version of > portage you already have. Portage is usually updated in EAPI > conservatively to minimize this issue, but if you want to jump > multiple years at a time it won't work. Jumping 6-12mo at a time will > minimize this issue. > > -- > Rich > > -- Thomas
