| I recently wrote a quip about this on the gentoo forums: https://forums.gentoo.org/viewtopic-t-1161242.html Basically, portage only ensures package consistency at the start and the end of a portage package transaction (upgrade, install, removal). Anywhere in the middle, if anything fails, or your package upgrades take too damn long and you need to use your system in the meantime, the programs you use can be subtly broken. This is especially painful when upgrading between ecosystems of packages with modules that are version-bound to eachother. Think for example python upgrade, Qt upgrades and KDE upgrades, that will simply not run until the entire stack has finished upgrading. This is a problem that many distributions deal with, but the chances of failure in binary distributions are much smaller, and the time taken between the two states wherein your system is "consistent" is significantly shorter. It'd be nice if portage was able to use a temporary system to build packages in, and only install onto the running system once everything has finished upgrading. Unfortunately, designing machinery for this is complicated, and most veteran gentoo users will suggest you use a chroot or a separate system to build packages for the system you're using. |
As you mention, this is true of every major Linux distro out there. In fact, in the nearly twenty years (ugh) that I've been using Gentoo, the only upgrade troubles I've run into are
* Temporary KDE screen locker problems (that is, the screen locker thinking it's "broken" and instructing me on how to manually unlock the session. (It didn't used to do this, and it was better when it didn't, because it would actually work.))
* Other KDE issues that are always solvable by some combination of restarting 'plasmashell' or 'kded'. (I'm super glad that both of those programs have a '--replace' flag. (And I haven't seen these particular problems in a very long time.))
* Firefox noticing that it got upgraded and refusing to let me work with anything that kicks off a new process
> ...most veteran gentoo users will suggest you use a chroot or a separate system to build packages for the system you're using.
Wild. I definitely fit the criteria for "veteran Gentoo user", and I would never, ever suggest that as a way to avoid the problem you're talking about.
AIUI, it won't work, or will be _complicated_ to set up (as programs not-infrequently need to build against new versions of libs, so you must _install_ those library packages in order to correctly build the packages that require them), or is identical to a binpkg build box (which -last I checked- was only encouraged if you had either a _very_ underpowered machine as your daily driver and a beefy build-box somewhere, or many, many systems that all could make use of the same set of packages, so saving time and power by having those packages built only once made sense).
EDIT: I looked at your forum post. I think you're inferring _way_ too much from the fact that two people that the forum software has given the tag 'Veteran' suggested "building in a chroot and then copying the packages over" (which closer inspection reveals to be either an overly-complicated binpkg build box, or a binpkg build box running in a chroot), and "set up a binpkg build box". Two people recommending this to you as a possible solution is _not_ "most" of the userbase... and the forum software's rating of them has no direct bearing on how good of a Gentoo admin they are. (I'm pretty sure the forum software still rates me as a "Newbie", as I've only ever made like four or ten posts. Most of my conversation happened over email, IRC, and the bug tracker.)