[simoncion]

What do you mean by "incomplete system package updates"?

I don't _think_ I've encountered any such thing in the past 10+ years, but my assumption of what you mean might be incorrect.

(Other than rebuilding the three(!) copies of Chromium I have installed on my desktop, I don't remember encountering any notable packaging-related time sinks since the days of that nasty libpng upgrade way back when. IIRC, it was some terrible breaking change after an upgrade to 1.2 or 1.4 or some shit.)

[mid-kid]

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.

[simoncion]

> ...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.

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.)

[nubinetwork]

I used to moderate those forums. The ranks are based on post count, or whether you contributed to Gentoo in some form (forum moderator, infrastructure, ebuild developer, council/foundation member, etc).

The rank shouldn't be seen as a qualifier of how much you know about the distribution.

[mid-kid]

My comment regarding the suggestion was mostly to highlight that it's the easiest solution to the problem that people can think of, not to mean that most gentoo users actually maintain their systems like that. I consider it unnecessarily involved.

[simoncion]

But you literally said

> ...most veteran gentoo users will suggest you use...

That's doesn't really agree with the claim that

> ...[I didn't claim that] most gentoo users actually maintain their systems like that.

[mid-kid]

I'm not sure how my statements are contradictory. The solutions people suggest to solve a problem aren't necessarily the ones they use. Most people aren't as bothered by the issue as I am, and as such won't need to solve it.

[chlorion]

You can build binaries on Gentoo and update from the binaries you've built rather than compiling as you go!

You can build binaries for all of the packages that need to be updated by running the normal update command and adding "--buildpkgonly".

[mid-kid]

--buildpkgonly doesn't work for any packages whose dependencies aren't already fully satisfied, including being up-to-date. You simply cannot use --buildpkgonly for a world update save for the very trivial transactions, for which any of what I mentioned isn't a problem anyway.

[chlorion]

I did not realize you were a Gentoo contributor when I first responded!

This is an interesting problem for sure. I don't know enough about portage internals to know whether it could be fixed easily, but it would be very nice to have.

So far I haven't really ran into any consistency issues caused by non-atomic upgrades. The only thing that comes to mind is needing to restart a zsh instance that was running during an upgrade that included it, and Firefox will sometimes tell me it needs to restart!

I have a fairly fast CPU (ryzen 3900x) so the time spent in an inconsistent state is probably much shorter than it is for others, I suppose this is why it's never bothered me before.

[michaelmrose]

With ZFS I would think you could clone root pool, chroot clone, promote clone, potentially reboot. with ZFSBootMenu you can boot from an old version if need be.