That is nice and often gives more than one month's notice.
What is really not nice is the obession with pruning the versions for each package. For a specific package, there is no serious issue with keeping several old versions hanging around in the package tree. By default the package manager understands that and the user doesn't see them. But where there is some compatibility or build issue, the user would have the option of masking the latest and keep going on an earlier version: it would still build, usually with no extra effort. It would rebuild fast if you have a build cache. You could downgrade easily if you discover an issue weeks later.
But no: most maintainers where that matters delete the previous version as soon as the new one is half in. Not a helpful obsession.
I was also put off by that, but consider the maintainers perspective: The more versions, the more combinatorics (also considering install time), which means more ways for bugs to occur. Then someone files a bug, does not give all the dependencies' versions, once you have them ... there is little a maintainer can do with limited time when upstream says "update to the latest version we released". Old versions are remembered in the git repo history of the package tree IIRC.
Speaking as someone that maintains some old and dropped shit in my own overlay and GURU ( https://cgit.gentoo.org/repo/proj/guru.git ), the web archive and Gentoo's own git history are where I usually find old ebuilds. They are of limited use, too old and it's ancient EAPI where ebuild style used to be more complicated, most of the time it just makes sense to rewrite the ebuild in EAPI 8 if needed. The main things I'm looking for are the notes and stuff like custom initscripts that might have been written.
If a dropped package is of interest and there's a reason it shouldn't be in the tree I usually submit it to GURU. If I use it and it probably should be saved or re-added to the tree I proxy maintain it.
Thank you! I don't live in git and this helps! Normally under gentoo I shouldn't have to. This actual git https://github.com/gentoo/gentoo (as opposed to the gentoo browser view) plus this "checkout the commit" should get me much further. ... And probably deserve some space in the gentoo docs.
It's not a difficult process to maintain your own repo overlay that keeps old packages for longer than the mainline.
One reason they are trimmed is because old version of $package don't build with new version of $library which is a big dependency (eg vte) that is moving forward so keeping the old ones, and maintaining them gets more and more difficult as time moves on. It's not Gentoo forcing the churn, it's the things Gentoo packages that are churning and it becomes visible at the Gentoo layer.
But your own overlay, or just pinning your build can easily solve that (eg, still using PostgreSQL 9)
It's easy to copy things into your own overlay IF you get notice that this version is going away.
Rarely, you might need to keep a dependency around. But no, usually the earlier packages still build just fine for a very long time. In the case of a high-churn package like chromium, there is a reason to be on latest - all the security patches - but when the latest doesn't build, the previous one is already gone (and would have built just fine.)
I’ve made many a trip to the git repo to dig up older versions and copy down the old version ebuilds into my own overlay: https://github.com/gentoo/gentoo
This is what made me leave gentoo, I would have to constantly remove or rebuild things that just worked fine and had no issues. I really didn't like the constant churn with gentoo so I left after using it since 2009.
i've been maintaining and deploying gentoo for about 20 years now, and when i have a machine that is working, where there's no chance that i or anyone else will need to edit the software, i just fail2ban and whitelist IPs that can SSH in. There's no reason for me to keep a CIFS server constantly updated if it's backnet only, for example.
This is especially true with machines that run things on GPUs.
p.s. i am maybe well known in some gentoo circles as the person who updates machines after 12-18 months. So i'll hit every bug and gotcha over a weekend that everyone else dealt with in the past year. This occurs mostly on desktop gentoo, stuff like pipewire and the DE stack. Occasionally python will threaten to brick a machine, but tinderbox et al have gotten me out of those jams.
With debian/ubuntu, once i get something running, that's what's on that machine until i decommission the machine or the stack running on it. I don't have the time or inclination to deal with things like that. That's what containers and VMs are for.
Do one emerge -avuDN world, and everything is upgraded... Now i have a browser with 50 tabs, a few processes running, chat windows, some hand-run services, a bunch of stuff, and suddenly, everything video related slows down to a crawl... API mismatch, nvidia kernel modules is one version and the 'frontend' libraries are a new version.
Swap kernel module? Nope, not without (at minimum) restarting X. Want to downgrade the frontend libs? Nope, the ebuild has been removed. Then either reboot, waste 20 minutes to set up everything, then 2 more phonecalls, since some service to test something "just for two hours, until the meeting" was running in screen for months now, and isn't running now, and after a --sync, a new version of nvidia drivers appear.... or find the old ebuild, put it in a personal overlay, and waste 20 minutes on that.
It's a pain. Just keep the old versions, an ebuild is a few kilobytes!
What is really not nice is the obession with pruning the versions for each package. For a specific package, there is no serious issue with keeping several old versions hanging around in the package tree. By default the package manager understands that and the user doesn't see them. But where there is some compatibility or build issue, the user would have the option of masking the latest and keep going on an earlier version: it would still build, usually with no extra effort. It would rebuild fast if you have a build cache. You could downgrade easily if you discover an issue weeks later.
But no: most maintainers where that matters delete the previous version as soon as the new one is half in. Not a helpful obsession.