Re: [gentoo-user] Re: trying to upgrade some old, never upgraded image for an embedded system …

[Thomas Schweikle]

I've created a bug report out of this. Stage3-files shall be upgraded at
least every time an EAPI-Bump would have had been done. EAPI versions of
stage3-files and therefore portage-tools shall match what files within the
portage-tree give.
If the is not the case, it will be nearly impossible to set up an
upgradeable system.

On Wed, Dec 18, 2019 at 7:15 PM Rich Freeman <rich0@g.o> wrote:

> On Wed, Dec 18, 2019 at 11:03 AM Grant Edwards
> <grant.b.edwards@×××××.com> wrote:
> >
> > On 2019-12-18, <nunojsilva@×××××××.pt> (Nuno Silva) <
> nunojsilva@×××××××.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