In the Overview of cross-architecture portability problems, I have dedicated a section to the problems resulting from use of 32-bit time_t type. This design decision, still affecting Gentoo systems…
I imagine the “update from another system” path runs in troubles with more complex gentoo installs than just the base system. For a full update from the live disk it will have to include lots and lots of (often exotic) tools that might be used in the building process (document generators like doxgen, lexer, testing frameworks, several build systems and make-likes. programming languages…) in addition to being able to build against the already installed updates for packages while not accidental building against packages that are not updated yet.
Or you go the simpler way and only do a base update from the live-system…only update the base build system and package management of the gentoo system and afterwards boot in a “broken” system in which only the basics works and rebuild it from there.
For be both those options sound less desirable than what is suggested in the blog.
I imagine the “update from another system” path runs in troubles with more complex gentoo installs than just the base system. For a full update from the live disk it will have to include lots and lots of (often exotic) tools that might be used in the building process (document generators like doxgen, lexer, testing frameworks, several build systems and make-likes. programming languages…) in addition to being able to build against the already installed updates for packages while not accidental building against packages that are not updated yet.
Or you go the simpler way and only do a base update from the live-system…only update the base build system and package management of the gentoo system and afterwards boot in a “broken” system in which only the basics works and rebuild it from there.
For be both those options sound less desirable than what is suggested in the blog.