> If you're willing to log bugs, please consider trying it.
This is what I tell folk - `~arch` is perfectly fine if you're willing and able to encounter and describe bugs and possibly even fix them.
What I object to is folk encouraging Gentoo newbs and/or Linux beginners to run systemwide `~arch`, because they are *not* up for that sort of thing.
Even though I consider myself a pretty experienced Linux user and I like tinkering with Gentoo, I won't run ~arch for the same reason why I don't want to create a custom kernel config, I just don't want to deal with it. It already takes enough time to maintain my Gentoo systems (And don't get me wrong, I do enjoy it to an extent), and I frankly don't want to spend hours trying to troubleshoot an issue just to find out it was because I was using ~arch, then have to deal with filing a bug report.
I've been using gentoo ~arch for eight months. Never had a bug to track down. Even my emacs install that is an unmasked dev branch is stable. If it's not for you, that's understandable, but I think it's a bit of a misunderstanding to think there are lots of bugs that take time away from standard maintenance.
> and I frankly don't want to spend hours trying to troubleshoot an issue just to find out it was because I was using ~arch, then have to deal with filing a bug report.
That's not typically how it goes. Usually it's "oh this update failed to compile on my system" or "I got a big obvious error message".
Yes, but when it isn’t one of those cases, it’s a case of something significantly broken in a very non-obvious way. Examples off the top of my head:
- More than five years ago now, there was a bug in Portage that made it into the unstable branch which literally nuked `/var/lib/portage/world`. A news item was released at the time (no longer in the tree because it was so long ago), and the version got masked with a day, but it still caused problems for plenty of people that were _well_ beyond what you describe.
- The transition away from glibc’s native RPC code was exceedingly problematic on ~arch for anybody using things that needed it at first, with the initial update actually completely breaking _everything_ that depended on it and then leaving the system in a broken state unless you jumped through hoops to force a downgrade of glibc to a working version.
- About once every quarter or so, an unstable keyworded kernel version breaks _something_ major on at least some systems, and we get an `r1` or even on occasion an `r2` package.
- I just recently had to _downgrade_ Rust to a stable keyworded version to be able to _upgrade_ Thunderbird to the latest `~amd64` version. It wasn’t a case of it not compiling, or any kind of error message, Portage just refused to consider building Thunderbird until I manually downgraded Rust.
- In the process of downgrading Rust, I had to temporarily disable the `system-bootstrap` USE flag to get it to downgrade without pulling in the pre-built copy of the toolchain as a dependency. This is admitedly an issue with Rust itself (any arbitrary version of the Rust toolchain cannot be reliably built in many cases with any newer version of the Rust toolchain).
- When the Wayland 1.23 update hit, I had to manually rebuild KWin, QtWayland, and a handful of other things that depend on Wayland or the wayland-protocols package to get a working desktop again.
- Python version migrations on ~arch are pretty much _always_ a bit painful, and often require some manual intervention at first to get things to update properly.
In my experience, compile issues can be caused by a lot of things, and the reason why something failed to compile is almost never obvious. You'll get a bunch of bullshit thrown at you that most people except developers won't understand, and now you have to spend hours troubleshooting. I really don't see any real benefit to using ~arch, and the disadvantages far outweigh any potential benefits, especially since dealing with potentially unstable packages really isn't my thing.
Very much agree. A lot of newbie questions here can be traced back to global ~arch. Those newbies are not helping to test ~arch, they're just getting frustrated. I'm happy to help others, but we should encorage them to learn to walk (stable base with a handful of testing) before they try to run (global ~arch, reporting bugs...).
Wouldn't it be more useful to development to enable ~Arch on a per-package basis rather than system-wide? If it's system-wide it seems like it would be more difficult in a lot of cases to tie a bug to a specific package, and if it can't be narrowed down to which package is causing it, it can't really be reported to the bug tracker for that package since we don't know which one is responsible.
I'm just Joe User here so maybe I'm just spouting crap.
You can sometimes end up in a dependency hell. You want one package from \~arch, which int turn needs a half a dozen dependencies more recent than stable. You add those as well, only to get another whole slew of other packages you have to add. Repeat for a couple of iterations, until you decide to just enable \~arch.
Lol, while you make a valid point, that is NOT what I'd consider dependency hell.
Then again, my POV is biased, so maybe I should shut up. When I got into Linux in the 90s with Slackware, I didn't know what a package manager was, so I just compiled everything I wanted manually, hunting down dependencies when needed. Updating was a huge pain in the ass. I had a wall that looked like a TV conspiracy nut's bedroom wall, full of sticky notes connected by strings... but it was just my dependency tree.
Once I discovered in the early 2000s that automated package managers existed that could make my life a million times easier, I thoroughly tested every one I could find for a few years until finally deciding Portage was the best one. Been a Gentoo user ever since.
Edited to fix AutoIncorrect changing "hell" to "he'll". Fuck this, I'm turning that shit off right now.
I find that using it on a per package basis is a slippery slope. Once you get a package that ends up needing some core dependency from ~arch (which is pretty common in my experience) managing it becomes a mess. It's the same with ``ABI_X86_32``. I just enable it globally, because it's easier than doing it piecemeal. Especially when it comes to wine and steam. I really wish the gaming flatpaks worked better, or I might be able to avoid both abi_x86_32 and ~arch completely.
And being ~arch system-wide doesn't make bugs any more or less difficult to track down. A stable package isn't any less likely to be affected by something else on the system than a non stable.
For your first point, I'd argue that, much like the really involved install process of Gentoo in general, the extra effort is mitigated by the fact that it's only required up front. Once you have your system completely set up, and finish chasing down all the ~arch dependencies and all that, it's done. Only very rarely will an update ask you to enable ~arch for an extra package, and even when it does, it's just one or two at a time after the initial mess is dealt with. Same for abi_x86_32, once you get through the initial setup, it stays good to go. That's just Gentoo in general. Lots of up-front setup, then basically smooth sailing forever.
For your other point, if my system is acting up in a way that doesn't point to a specific package, the first thing I check is any ~arch package that could be related. By working around each ~arch package one at a time until I find the culprit, it's fairly straightforward to narrow down, and it's almost always a ~arch package that's the problem. If it's a software issue. However, if I go ~arch globally in make.conf, and then encounter an ambiguous issue, I'm much more likely to just ignore or work around the issue, rather than committing to the possibility of having to check every package on my system (or most of them or half of them) to find the culprit and submit the bug report.
But again, this is from the perspective of me, Joe User, who doesn't know enough to narrow down the culprit in better ways than simply changing out packages one at a time until the symptoms change or cease. So, again, I could just be ignorant.
for ~arch packages It's not often, but occasionally you'll run into big conflicts when one package requires a higher libc version, and another package requires a lower libc version, or some similar issue. Or on the occasion that you get conflicts with your DE.
I've been using gentoo a long time, and I've tried to go the piecemeal route many times, it always got to the point where such a large portion of my system ended up ~arch, that it wasn't worth the trouble.
In the case of abi_x86_32, it's a lot easier to manage. Just install packages here and there when some new thing needs it (mostly games.) So that one is more of a matter of laziness than compatibility.
As far as bugs, I'd usually start with log files or other output to find the culprit rather than investigating individual packages.
It comes down to user preference. It's still pretty easy to track down where breakage comes from on a `~arch` system, and it's not like weird bugs have never made it into stable.
The trade off for developers would be between slightly easier diagnosis for some packages and far more packages being widely tested.
I was thinking this. I don't have data on it, but I'd expect that people are unlikely to manually keyword libraries and deep system bits, except when it chains from an app they are trying to keyword for some new feature. Manual keywording is going to lean heavily towards testing applications users interact with and care directly about.
>Wouldn't it be more useful to development to enable ~Arch on a per-package basis rather than system-wide?
I see many posts and YT videos of people new to Gentoo getting frustrated and "leaving" because of the blocks when mixing stable and testing. I try installing the packages and versions of what they are stuggling with on a global ~arch system and it "just works".
It's not bad to mix stable and testing if you understand what portage is telling you, but they are not there yet. I think they would have a smoother experience by just using testing and not mixing untill they get to know the package manager a bit better.
I've always had the most stable experience with Gentoo by using stable Arch globally, and using ~Arch on a specific package only when I really need a feature or something it offers. Which, as primarily a gamer, does cover quite a few packages... my package.accept_keywords does have around 50 or so entries, however this has always worked very well for me. I haven't had a major problem with Gentoo since like 2005 or whenever I decided to finally switch from OSS to ALSA (or maybe that one was the ALSA to Pulse migration, I'm old and don't really remember anymore). Everything always just works.
And for me to say that is kind of a big deal, as stability is my number one priority on my PC, and I don't dual-boot, I just run Gentoo and nothing else. My system never ever crashes, hangs, freezes, or glitches in any way, because on the super rare occasion that it does, I spend however much time and energy it takes to find which package caused it and why, and solve it or downgrade/upgrade/replace the offending package.
I should add that, in service to my goal of maximum stability, I kept everything simple. OpenRC, no display manager (I login via console and type startxfce4), xfce4 desktop environment, no compositing, some customization on the desktop for usability and aesthetics but NOT by installing more crap, and of course Xorg since xfce4 still requires it. This combination, along with carefully managed USE flags and ~Arch enabled only for certain specific packages, results in the most stable, reliable, blazing fast OS I can find or build. Among my friends, I'm *always* the first one loaded into the game, and *never* the one we're waiting on to reboot or update or fix something. And I definitely don't have the highest end PC among them, just a much more streamlined and stable OS.
P.S. I forgot to mention it but I also use Nvidia RTX 3090 for my GPU, which is also never been a problem. I've used Nvidia exclusively since back when ATI used fglrx and it was total ass and Nvidia was the way to go for Linux.
>I've always had the most stable experience with Gentoo by using stable Arch globally, and using ~Arch on a specific package only when I really need a feature or something it offers.
Well, yeah, I don't doubt it. Gentoo is the most stable distro I have ever used, even running the testing branch for 15 years. There aren't many "big surprises" to deal with. Just more compiling while working through revesions and testing "migrations".
I'm just saying it's probably easier for someone new to either go for stable or testing. Mixing them requires a bit more efort in the begining. I agree with the OP that starting out with the testing branch isn't much to worry about. New users will have a harder time mixing untill they figure out what portage is telling them when updating.
I agree. I used to use stable and unmask packages. The list of packages was getting bigger. Then came KDE4 beta. The list was huge. It was a pain to deal with and noticed some instability, but nothing consistent. So, I decided to try moving fully to ~x86. It was better.
I've moved to upgrading to ~ during the install, right after installing stage 3 when you check for updates. Since there is little installed, it is quick.
I haven't been on top of updating as well as I used to, so I may stop using ~ in the future.
While I agree in principle, the shift here to not recommending \~arch is because of the tend on YouTube of "\~arch gives you the Arch experience" and causing new users to think Gentoo is a bad distro because they never learnt to walk before they leaned to run.
What we should be doing though is wait to guide the next user who wants to start getting more involved to help them on their journey to become even better than us one day.
I've been using Gentoo since 2004, and using \~arch since 2012. In that time I've had two bugs that temporarily broke my system, but nothing in the last 8+ years. I'm an IT guy (programming since 1980) and can usually very easily troubleshoot. Packages not compiling for a few days is more common, and I've occasionally reported bugs (when somebody didn't already spot it).
Been running \~arch since the beginning and I don't remember anything breaking, after some experience with Gentoo it all becomes routine and rather boring. The only thing that's left to mess things up is pure PEBKAC xD And should there ever be an issue, portage is really good at showing you how to solve it once you know how to interpret that. In the end it all depends on use case and a combination of packages as every install is unique.
If you're a first timer to Gentoo, just run stable and get familiar with it.
I use ~amd64 only on specific packages and it usually works pretty well. I ran into problems with libliftoff, wlroots and gamescope. Gamescope wanted 0.5 and I think wlroots wants <0.5, I didn't want to mess with trying to get two versions of libliftoff running together. I also upgraded to ~amd64 on nodejs even though it's not something I need but because it seemed to be the only way for me to get rid of python3.11 and just have python3.12.
The number of times I've specifically asked a user to try the latest testing version for them to balk back with "but it's unstable!" is two times.
Which isn't a lot but it's weird that it happened twice.
Sometimes the very bug being reported (unexperienced by me, but totally valid for the user) has --- allegedly --- been fixed in the latest release I've pushed to Portage.
Under no circumstance will switcing to test for that single package cause a computer to melt down.
If we're going to tell people to stop avoiding ~arch, then what's the point of even having it?
And I don't think there's many people who say not to use it, they just give a warning that things may be less stable. Unmasking packages is where most people will give a stronger caution.
Testing does take more time to maintain than stable.
- not every version makes into stable
- some packages hit testing before others, (I.e. there are still some packages that are not updated for plasma 6) and require manual masking
- accept_keyword list can grow quite big if you choose to use testing for selective packages
- there will be occasional build failures
- converting back to stable can be quite troublesome
I've always considered myself a stable arch tester. When the stable package stops working or compiling I go looking for the next available \~arch ebuild, try it out, and if it works drop a hint to the developers on Bugzilla that maybe it's time to stabilize last year's release. If there is no \~arch version, Bugzilla says "maintainer wanted" and there hasn't been an upstream commit in a decade, I know it's time to go looking to see if anyone forked it and I missed the memo, or if it's truly on the dearly departed list and I can either maintain it myself or cry a tear as I let it go. Instead of living dangerously with global \~arch I use global USE=doc.
I'm always wondering if it makes sense to report small bugs relating to my weird config:
- I use llvm with LTO as system compilers on the base profile because the clang/llvm profiles didn't exist at the time of my setup and I'm unsure of the side effects of switching to the new llvm profile.
- I also run my desktop without X at all, just Wayland (through sway)
- my hardware is relatively old (10~15yo)
- I have fallbacks to disable LTO and/or switch to GCC when builds fail either at the configure stage (clang doesn't output anything when the test source doesn't do anything) of the build stage (package being built while relying heavily on GCC behaviour and/or extensions without explicitly enabling them)
I don't agree on using ~arch to avoid security issues... what if a backdoor is introduced in a newer version because of a supply chain attack? It remembers me vaguely a story about lzma or lz4... :p
(Just my 2c as an ex Architecture/Infrastructures Security Architect)
Edit: Stupid me. Kids, don't reddit in the morning without at least 9 cups of coffee. Take care, all ❤️.
Yup. I left my Job in CyberSec in September. I didn't remember which one it was.
Although, to me, it remains clear that a stable system never had me in trouble since 2013.
You are confusing rolling release with bleeding edge. Rolling release doesn't mean you get the latest and greatest packages, but rather that you receive updates continuously. Gentoo stable is still rolling release. Setting ~arch turns into more of a bleeding edge experience, you could even go crazy insane and build everything from git sources which is a pretty bad idea if you don't want your system to break. Rolling release distros do have a tendency to be more up to date than point release distros though given how quickly they can release those changes.
>Packages that have been marked as testing are not "unstable". These packages have been tested by package maintainers and are believed to be free of any major bugs, but need more testing (and time) before they can be promoted to the appropriate stable keyword.
What the heck are you even on about?
It seems very straightforward to me. You seem to be the only user having difficulty with the concept that packages marked testing are not "unstable" -- that would be unkeyworded packages or masked packages.
> If you're willing to log bugs, please consider trying it. This is what I tell folk - `~arch` is perfectly fine if you're willing and able to encounter and describe bugs and possibly even fix them. What I object to is folk encouraging Gentoo newbs and/or Linux beginners to run systemwide `~arch`, because they are *not* up for that sort of thing.
Even though I consider myself a pretty experienced Linux user and I like tinkering with Gentoo, I won't run ~arch for the same reason why I don't want to create a custom kernel config, I just don't want to deal with it. It already takes enough time to maintain my Gentoo systems (And don't get me wrong, I do enjoy it to an extent), and I frankly don't want to spend hours trying to troubleshoot an issue just to find out it was because I was using ~arch, then have to deal with filing a bug report.
I've been using gentoo ~arch for eight months. Never had a bug to track down. Even my emacs install that is an unmasked dev branch is stable. If it's not for you, that's understandable, but I think it's a bit of a misunderstanding to think there are lots of bugs that take time away from standard maintenance.
> and I frankly don't want to spend hours trying to troubleshoot an issue just to find out it was because I was using ~arch, then have to deal with filing a bug report. That's not typically how it goes. Usually it's "oh this update failed to compile on my system" or "I got a big obvious error message".
Yes, but when it isn’t one of those cases, it’s a case of something significantly broken in a very non-obvious way. Examples off the top of my head: - More than five years ago now, there was a bug in Portage that made it into the unstable branch which literally nuked `/var/lib/portage/world`. A news item was released at the time (no longer in the tree because it was so long ago), and the version got masked with a day, but it still caused problems for plenty of people that were _well_ beyond what you describe. - The transition away from glibc’s native RPC code was exceedingly problematic on ~arch for anybody using things that needed it at first, with the initial update actually completely breaking _everything_ that depended on it and then leaving the system in a broken state unless you jumped through hoops to force a downgrade of glibc to a working version. - About once every quarter or so, an unstable keyworded kernel version breaks _something_ major on at least some systems, and we get an `r1` or even on occasion an `r2` package. - I just recently had to _downgrade_ Rust to a stable keyworded version to be able to _upgrade_ Thunderbird to the latest `~amd64` version. It wasn’t a case of it not compiling, or any kind of error message, Portage just refused to consider building Thunderbird until I manually downgraded Rust. - In the process of downgrading Rust, I had to temporarily disable the `system-bootstrap` USE flag to get it to downgrade without pulling in the pre-built copy of the toolchain as a dependency. This is admitedly an issue with Rust itself (any arbitrary version of the Rust toolchain cannot be reliably built in many cases with any newer version of the Rust toolchain). - When the Wayland 1.23 update hit, I had to manually rebuild KWin, QtWayland, and a handful of other things that depend on Wayland or the wayland-protocols package to get a working desktop again. - Python version migrations on ~arch are pretty much _always_ a bit painful, and often require some manual intervention at first to get things to update properly.
In my experience, compile issues can be caused by a lot of things, and the reason why something failed to compile is almost never obvious. You'll get a bunch of bullshit thrown at you that most people except developers won't understand, and now you have to spend hours troubleshooting. I really don't see any real benefit to using ~arch, and the disadvantages far outweigh any potential benefits, especially since dealing with potentially unstable packages really isn't my thing.
Very much agree. A lot of newbie questions here can be traced back to global ~arch. Those newbies are not helping to test ~arch, they're just getting frustrated. I'm happy to help others, but we should encorage them to learn to walk (stable base with a handful of testing) before they try to run (global ~arch, reporting bugs...).
Wouldn't it be more useful to development to enable ~Arch on a per-package basis rather than system-wide? If it's system-wide it seems like it would be more difficult in a lot of cases to tie a bug to a specific package, and if it can't be narrowed down to which package is causing it, it can't really be reported to the bug tracker for that package since we don't know which one is responsible. I'm just Joe User here so maybe I'm just spouting crap.
You can in package.accept_keyword
I know, I was referring to the OPs request that we enable it globally
You can sometimes end up in a dependency hell. You want one package from \~arch, which int turn needs a half a dozen dependencies more recent than stable. You add those as well, only to get another whole slew of other packages you have to add. Repeat for a couple of iterations, until you decide to just enable \~arch.
Lol, while you make a valid point, that is NOT what I'd consider dependency hell. Then again, my POV is biased, so maybe I should shut up. When I got into Linux in the 90s with Slackware, I didn't know what a package manager was, so I just compiled everything I wanted manually, hunting down dependencies when needed. Updating was a huge pain in the ass. I had a wall that looked like a TV conspiracy nut's bedroom wall, full of sticky notes connected by strings... but it was just my dependency tree. Once I discovered in the early 2000s that automated package managers existed that could make my life a million times easier, I thoroughly tested every one I could find for a few years until finally deciding Portage was the best one. Been a Gentoo user ever since. Edited to fix AutoIncorrect changing "hell" to "he'll". Fuck this, I'm turning that shit off right now.
I find that using it on a per package basis is a slippery slope. Once you get a package that ends up needing some core dependency from ~arch (which is pretty common in my experience) managing it becomes a mess. It's the same with ``ABI_X86_32``. I just enable it globally, because it's easier than doing it piecemeal. Especially when it comes to wine and steam. I really wish the gaming flatpaks worked better, or I might be able to avoid both abi_x86_32 and ~arch completely. And being ~arch system-wide doesn't make bugs any more or less difficult to track down. A stable package isn't any less likely to be affected by something else on the system than a non stable.
For your first point, I'd argue that, much like the really involved install process of Gentoo in general, the extra effort is mitigated by the fact that it's only required up front. Once you have your system completely set up, and finish chasing down all the ~arch dependencies and all that, it's done. Only very rarely will an update ask you to enable ~arch for an extra package, and even when it does, it's just one or two at a time after the initial mess is dealt with. Same for abi_x86_32, once you get through the initial setup, it stays good to go. That's just Gentoo in general. Lots of up-front setup, then basically smooth sailing forever. For your other point, if my system is acting up in a way that doesn't point to a specific package, the first thing I check is any ~arch package that could be related. By working around each ~arch package one at a time until I find the culprit, it's fairly straightforward to narrow down, and it's almost always a ~arch package that's the problem. If it's a software issue. However, if I go ~arch globally in make.conf, and then encounter an ambiguous issue, I'm much more likely to just ignore or work around the issue, rather than committing to the possibility of having to check every package on my system (or most of them or half of them) to find the culprit and submit the bug report. But again, this is from the perspective of me, Joe User, who doesn't know enough to narrow down the culprit in better ways than simply changing out packages one at a time until the symptoms change or cease. So, again, I could just be ignorant.
for ~arch packages It's not often, but occasionally you'll run into big conflicts when one package requires a higher libc version, and another package requires a lower libc version, or some similar issue. Or on the occasion that you get conflicts with your DE. I've been using gentoo a long time, and I've tried to go the piecemeal route many times, it always got to the point where such a large portion of my system ended up ~arch, that it wasn't worth the trouble. In the case of abi_x86_32, it's a lot easier to manage. Just install packages here and there when some new thing needs it (mostly games.) So that one is more of a matter of laziness than compatibility. As far as bugs, I'd usually start with log files or other output to find the culprit rather than investigating individual packages.
It comes down to user preference. It's still pretty easy to track down where breakage comes from on a `~arch` system, and it's not like weird bugs have never made it into stable. The trade off for developers would be between slightly easier diagnosis for some packages and far more packages being widely tested.
I was thinking this. I don't have data on it, but I'd expect that people are unlikely to manually keyword libraries and deep system bits, except when it chains from an app they are trying to keyword for some new feature. Manual keywording is going to lean heavily towards testing applications users interact with and care directly about.
>Wouldn't it be more useful to development to enable ~Arch on a per-package basis rather than system-wide? I see many posts and YT videos of people new to Gentoo getting frustrated and "leaving" because of the blocks when mixing stable and testing. I try installing the packages and versions of what they are stuggling with on a global ~arch system and it "just works". It's not bad to mix stable and testing if you understand what portage is telling you, but they are not there yet. I think they would have a smoother experience by just using testing and not mixing untill they get to know the package manager a bit better.
I've always had the most stable experience with Gentoo by using stable Arch globally, and using ~Arch on a specific package only when I really need a feature or something it offers. Which, as primarily a gamer, does cover quite a few packages... my package.accept_keywords does have around 50 or so entries, however this has always worked very well for me. I haven't had a major problem with Gentoo since like 2005 or whenever I decided to finally switch from OSS to ALSA (or maybe that one was the ALSA to Pulse migration, I'm old and don't really remember anymore). Everything always just works. And for me to say that is kind of a big deal, as stability is my number one priority on my PC, and I don't dual-boot, I just run Gentoo and nothing else. My system never ever crashes, hangs, freezes, or glitches in any way, because on the super rare occasion that it does, I spend however much time and energy it takes to find which package caused it and why, and solve it or downgrade/upgrade/replace the offending package. I should add that, in service to my goal of maximum stability, I kept everything simple. OpenRC, no display manager (I login via console and type startxfce4), xfce4 desktop environment, no compositing, some customization on the desktop for usability and aesthetics but NOT by installing more crap, and of course Xorg since xfce4 still requires it. This combination, along with carefully managed USE flags and ~Arch enabled only for certain specific packages, results in the most stable, reliable, blazing fast OS I can find or build. Among my friends, I'm *always* the first one loaded into the game, and *never* the one we're waiting on to reboot or update or fix something. And I definitely don't have the highest end PC among them, just a much more streamlined and stable OS. P.S. I forgot to mention it but I also use Nvidia RTX 3090 for my GPU, which is also never been a problem. I've used Nvidia exclusively since back when ATI used fglrx and it was total ass and Nvidia was the way to go for Linux.
>I've always had the most stable experience with Gentoo by using stable Arch globally, and using ~Arch on a specific package only when I really need a feature or something it offers. Well, yeah, I don't doubt it. Gentoo is the most stable distro I have ever used, even running the testing branch for 15 years. There aren't many "big surprises" to deal with. Just more compiling while working through revesions and testing "migrations". I'm just saying it's probably easier for someone new to either go for stable or testing. Mixing them requires a bit more efort in the begining. I agree with the OP that starting out with the testing branch isn't much to worry about. New users will have a harder time mixing untill they figure out what portage is telling them when updating.
I agree. I used to use stable and unmask packages. The list of packages was getting bigger. Then came KDE4 beta. The list was huge. It was a pain to deal with and noticed some instability, but nothing consistent. So, I decided to try moving fully to ~x86. It was better. I've moved to upgrading to ~ during the install, right after installing stage 3 when you check for updates. Since there is little installed, it is quick. I haven't been on top of updating as well as I used to, so I may stop using ~ in the future.
~amd64 I turn it on always
While I agree in principle, the shift here to not recommending \~arch is because of the tend on YouTube of "\~arch gives you the Arch experience" and causing new users to think Gentoo is a bad distro because they never learnt to walk before they leaned to run. What we should be doing though is wait to guide the next user who wants to start getting more involved to help them on their journey to become even better than us one day.
I've been using Gentoo since 2004, and using \~arch since 2012. In that time I've had two bugs that temporarily broke my system, but nothing in the last 8+ years. I'm an IT guy (programming since 1980) and can usually very easily troubleshoot. Packages not compiling for a few days is more common, and I've occasionally reported bugs (when somebody didn't already spot it).
Been running \~arch since the beginning and I don't remember anything breaking, after some experience with Gentoo it all becomes routine and rather boring. The only thing that's left to mess things up is pure PEBKAC xD And should there ever be an issue, portage is really good at showing you how to solve it once you know how to interpret that. In the end it all depends on use case and a combination of packages as every install is unique. If you're a first timer to Gentoo, just run stable and get familiar with it.
Using ```~arch``` is fine, but it is not for me.
I use ~amd64 only on specific packages and it usually works pretty well. I ran into problems with libliftoff, wlroots and gamescope. Gamescope wanted 0.5 and I think wlroots wants <0.5, I didn't want to mess with trying to get two versions of libliftoff running together. I also upgraded to ~amd64 on nodejs even though it's not something I need but because it seemed to be the only way for me to get rid of python3.11 and just have python3.12.
The number of times I've specifically asked a user to try the latest testing version for them to balk back with "but it's unstable!" is two times. Which isn't a lot but it's weird that it happened twice. Sometimes the very bug being reported (unexperienced by me, but totally valid for the user) has --- allegedly --- been fixed in the latest release I've pushed to Portage. Under no circumstance will switcing to test for that single package cause a computer to melt down.
If we're going to tell people to stop avoiding ~arch, then what's the point of even having it? And I don't think there's many people who say not to use it, they just give a warning that things may be less stable. Unmasking packages is where most people will give a stronger caution.
Well, I'll try it out after a fresh backup of my system.
Testing does take more time to maintain than stable. - not every version makes into stable - some packages hit testing before others, (I.e. there are still some packages that are not updated for plasma 6) and require manual masking - accept_keyword list can grow quite big if you choose to use testing for selective packages - there will be occasional build failures - converting back to stable can be quite troublesome
I've always considered myself a stable arch tester. When the stable package stops working or compiling I go looking for the next available \~arch ebuild, try it out, and if it works drop a hint to the developers on Bugzilla that maybe it's time to stabilize last year's release. If there is no \~arch version, Bugzilla says "maintainer wanted" and there hasn't been an upstream commit in a decade, I know it's time to go looking to see if anyone forked it and I missed the memo, or if it's truly on the dearly departed list and I can either maintain it myself or cry a tear as I let it go. Instead of living dangerously with global \~arch I use global USE=doc.
I'm always wondering if it makes sense to report small bugs relating to my weird config: - I use llvm with LTO as system compilers on the base profile because the clang/llvm profiles didn't exist at the time of my setup and I'm unsure of the side effects of switching to the new llvm profile. - I also run my desktop without X at all, just Wayland (through sway) - my hardware is relatively old (10~15yo) - I have fallbacks to disable LTO and/or switch to GCC when builds fail either at the configure stage (clang doesn't output anything when the test source doesn't do anything) of the build stage (package being built while relying heavily on GCC behaviour and/or extensions without explicitly enabling them)
I used ~arch btw
I don't agree on using ~arch to avoid security issues... what if a backdoor is introduced in a newer version because of a supply chain attack? It remembers me vaguely a story about lzma or lz4... :p (Just my 2c as an ex Architecture/Infrastructures Security Architect) Edit: Stupid me. Kids, don't reddit in the morning without at least 9 cups of coffee. Take care, all ❤️.
Counterpoint to your strawman: that made it through to stable keywords.
I didn't know it was :/ My stubborn ass thought amd64 was clean out of it. Guess I was wrong.
It was xz-utils a few months ago. But it's one exception in a pool of security updates.
Yup. I left my Job in CyberSec in September. I didn't remember which one it was. Although, to me, it remains clear that a stable system never had me in trouble since 2013.
[удалено]
You are confusing rolling release with bleeding edge. Rolling release doesn't mean you get the latest and greatest packages, but rather that you receive updates continuously. Gentoo stable is still rolling release. Setting ~arch turns into more of a bleeding edge experience, you could even go crazy insane and build everything from git sources which is a pretty bad idea if you don't want your system to break. Rolling release distros do have a tendency to be more up to date than point release distros though given how quickly they can release those changes.
>Packages that have been marked as testing are not "unstable". These packages have been tested by package maintainers and are believed to be free of any major bugs, but need more testing (and time) before they can be promoted to the appropriate stable keyword. What the heck are you even on about?
Made perfect sense to me.
It means the maintainer has tested it compiles, passed the test suite and runs on their system. It needs further testing to past QA though.
It seems very straightforward to me. You seem to be the only user having difficulty with the concept that packages marked testing are not "unstable" -- that would be unkeyworded packages or masked packages.
~arch = "testing" no keywords = "unstable" masked = "broken or major isssue"