[mrslave]

Recovering Gentoo user here. I have lost so many hours to the time sink that is incomplete system package updates on Gentoo. Moved to Nix and never looked back.

On Nix either the install - and occasional build - succeeds and I enter the new environment, or it fails and I don't. In the worst case scenario where the build succeeds but something is funky I can just roll it back.

Now I have all this free time to lose to the time sink that is learning how to package applications in the Nix language.

[genchu]

I finally installed Gentoo last year for the first time. I am pleased to say that Gentoo will be my distro of choice for the foreseeable future.

One of the best aspects of Gentoo is how easy it is to understand its working parts (portage, openrc), and to customize/modify a working system. This is in contrast to, e.g., Debian/Ubuntu, which I used for years, and which bring in a lot more complexity to do the same things.

I'll also admit that while the theory of Nix always seemed to hold promise, I've never actually went through with installing it as a distro on a base system. To me, the premise of Nix---essentially, that it can provide an abstraction of pristine system state transitions---doesn't seem to mesh with the reality of physical computer systems; which is to say, state and mutability are not bugs, but features of your computer.

On source-based/"ports"-style package management: I think the way to approach portage is to put yourself in the role of a sysadmin in charge of maintaining a set of Gentoo installations. So, if you want binary packages, you will need to ensure it is set up right yourself (possibly using portage's own binpkg tools, or some other way). There's a certain DIY/rugged-individualism to this approach; but the design and implementation of Gentoo enable and encourage opening the engine hood.

[donio]

Long time Gentoo user for similar reasons: flexibility and transparency.

Similar thoughts about Nix too. Messed around with it in limited ways but it's not a good match for how I like to run my systems and I don't find the extra layer of complexity to be a good enough trade-off.

Frankly I am a bit surprised that I am still on Gentoo after all these years (decades), you'd think that something better[1] would come along. But if it's out there I have yet to find it.

[1] ...better for my personal preferences and use cases

[kaba0]

> which is to say, state and mutability are not bugs, but features of your computer.

We uniformly agreed that mutating machine code and source code (git) is a bad idea — why should our system’s binaries/configs be any different?

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

[FeepingCreature]

I went back to Gentoo from Nix.

Turns out I really like the ability to decide to just randomly edit some file to fix an issue, and also shellscripts.

[kaba0]

How is it different from Nix? Hell, it is much more easier/flexible with Nix, just clone nixpkgs and update a few files and build from that. You can have as many versions as you want.

[deadly_syn]

Because for moat other distros i can just `vim /etc/somedir/config` which is a lot less work than pulling a repo, finding the right files to modify and then rebuilding the entire package.

[charcircuit]

Nix's time sync is that you have to constantly fiddle with Nix because it's incompatible with the way a lot of other distributions work and they made it to complicated for end users to package software themselves without referencing a manual.

[wwarek]

> without referencing a manual.

Or even worse - the source code itself

[hawski]

I used Gentoo for my desktop around 15 years ago. It was a bit dumb in retrospect, but I learned a lot. Now I think that Gentoo works best as a base to create your own distribution (duh!). It is a meta-distribution after all.

If you build on the same machine you use it and there are no other machines it is mostly pointless. It should not come as a surprise that Yocto's bitbake was inspired by Portage. Other fun fact: ChromeOS is built on top of Portage.

[anthomtb]

I ran Gentoo for about 4 years (2017-2020). So many times you would get stuck needing some "masked off" package. And the advice on the Gentoo forum for getting yourself out of the pickle was usually: fresh install.

The trauma of that experience has left me with WSL as my sole Linux PC at home.

[chlorion]

This is pure misinformation at best.

A masked package is generally caused by something not being stabilized yet, which can be fixed by adding the package to the package.accept_keywords file.

Sometimes a package with known issues, such as security vulnerabilities will also be masked. These can also be installed by adding the package to the package.unmask file.

Your issues were caused by not reading the documentation and taking advice from random people on forums. Ironically portage will actually tell you what you need to do to unmask a package if you read it's output too!

I hope this doesn't come off as too rude, but it's wrong to blame the distro for your misuse of it, especially when there are heaps of documentation and help messages in the output!

[donio]

Huh, the last time I've done a "fresh install" was for the amd64 switch in 2008, my image has been rolling forward since then. I guess I am extremely lucky?

[anthomtb]

I would attribute a stable Gentoo system to skill and patience, not luck.

Out of curiosity, what is your use case for this particular Gentoo install? 15+ years is a long time to keep the same machine running.

[donio]

This particular one is my general purpose desktop. I use it for everything from Emacs, development, web browsing, games (Steam mostly) etc.

Physically there is nothing left of the original hardware as it has gone through many generations of part replacements, Ship of Theseus style. It's the OS image that has survived through all this. My /home which I keep separate is another 10 years older.

[filmor]

Could be multiple machines. I carried an image over three laptops, rebuilding with the new `-march` as I went along.

[donio]

Yeah, that's basically it but I use conservative CFLAGS, pretty much just "-O2" so no need to rebuild for CPU changes.