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.

It's not unfair of the maintainer to only maintain the current versions. That would be fine.

Old versions (ebuilds and patches) are really not easy to find once they are gone from the portage ebuild tree. I still don't know where they live.

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 @Sembiance and you!

When I somehow get to an old ebuild like perhaps gentoo/www-client/chromium /chromium-118.0.5993.54.ebuild here:

https://github.com/gentoo/gentoo/blob/3fb0eea1ee35033113d7af...

how do I find which gentoo portage 'files' were live at the time? (poor example - there may have been no change in this case.)

Checkout the commit? You'll have a local copy of the tree exactly as it was at that time.

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.