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!
Gentoo was my first proper Linux distro that I started using over a decade ago. As the time has gone by and I ended up using other distros for other purposes, I got exposed to the ways the other distros do things... which I often found to be unintuitive or confusing compared to Gentoo. It made realised just how lucky I was that I started off with a distro that pays such close attention to detail to so many things - like the one in the post. Gentoo was definitely one of the main reasons I found so much joy in Linux and resulted in the career that I have today.
A Dutch friend on a filesharing IRC network walked me through an install process on my old laptop, via Skype, throughout an entire evening and some of the night. I remember how we went through one-by-one enabling certain kernel modules and reading the descriptions of what they did.
I got my first job in the web world because I was using Gentoo at home, and that totally defined my career as well. The day I build again a desktop computer, I think I'm going to install it again (although waking up at 4AM to check why the kernel or Konqueror weren't compiling and fixing the flag or dependency issue is certainly something I will not do again)
You may or may not like FreeBSD. A lot of the packaging concepts in Gentoo came from ports (hence the name portage). FreeBSD has binary or source packages that can be mixed, is stable, and is slower moving than Linux (in a good way).
Having extensively used Gentoo on the desktop (laptop, even!) mostly just makes me grumpier at all the time and money we waste doing shit our OS could do for us with way less effort. But nobody likes those solutions these days, they want to re-invent system services as fragile, fiddly crap with a Web dashboard.
It’s handy to know because sometimes I can save day, but mostly just means I can name the older, better thing we’re spending a dump truck of money to do the hard, worse way.
I think a lot of the reason why I don't use Gentoo anymore is because the time I have to waste when I have to compile Chrome from scratch and wait two hours vs. just installing a precompiled .deb archive. :)
There is no source version of Chrome since it's closed source. I assumed GP meant chromium. A while back there was a chromium-bin for a short period, but it seems to have fallen out of maintenance and is now removed.
Oh man, I always install binary chrome-stable. Rust is another I don't enjoy building, so bin package there as well. But god forbid one of LLVM, QT and glibc chewing up all my CPU time every few months.
Truthfully, I never actually got to the rust build portion of the install. Rust required it's own patched version of LLVM to build, and I stopped there since I felt it was not worth compiling both, just for the one.
I recently installed Gentoo for the first time and I like it too. The installation process may be long but I think that's actually a strength if you're part of the target audience. The handbook is not just an installation guide but also an effective introduction to how Gentoo works and it just feels a bit more transparent to use.
> So I won’t get the helpful message if I happen to go more than a month between system updates. Which I think is a fairly generous window.
Gentoo was my first Linux distro and it was cool.. It definitely taught me a lot about app building. But the expectation that every machine needs to be continuously updated at least once per month is what caused me to go to Debian. You have that server which just works and you haven't logged in there for three months.. or a laptop which you only use for travel? Prepare for broken automated updates and careful package rebuilding in just the right order.
Yeah, this is nice. I bet something like this could easily be brought to systems like Arch/Pacman and NixOS/Nix if someone wanted to champion coming up with an implementation for those systems.
(Actually, this is definitely doable on Nix, since there are mechanisms like "insecure" packages, but 1. I dunno if there's any for this situation (block package without explicit confirmation because it's not maintained) 2. I don't think there's any policy for this, but it would be nice if there was at least a procedure for people who wanted this kind of deprecation. It's also a bit different on Nix since it is not a rolling release distribution.)
Completely agree. This seems a really nice approach in Gentoo. Am a big fan of Arch but I was immediately thinking this would be handy there - I'm pleased with the engagement/responsibility that Arch encourages but this kind of thing is always catching me out and I pay a fair amount of attention to my installations!
> If I run any package manager operations between the mask date and one month after the mask date, I’ll get this comment telling me the package is masked. After a month though, the package will get removed from tree along with the package mask (no need to mask a package which isn’t there anymore). So I won’t get the helpful message if I happen to go more than a month between system updates. Which I think is a fairly generous window.
A month is generous? I mean maybe for my desktop machine. Certainly not for some headless file server.
If you're going more than a month without updating a server, then you should allow for the possibililty of a bit of downtime (or delay to read the docs) when you do get around to updating it. And since it wasn't clear in the article: removing a package from the portage repo doesn't cause the package to be automatically uninstalled from your system, and it doesn't cause the package to be ignored during dependency resolution.
One thing I liked about Ubuntu was how they handled the Python 2 -> Python 3 transition after version 2 was officially no longer supported.
`python` was then a non-existent command which would fail while python3 continued to work.
This way one would not accidentally run a Python 2 script which kind of worked with Python 3 but then failed under very specific circumstances, possibly even after running for a couple of days. Not even letting that script start in the first place directly after the distro upgrade was the correct thing to do.
There's a pretty popular `python-is-python3` package in Ubuntu which aliases `python` to `python3`. I used to install that in my dev environment setup scripts, but have since stopped using it for the reasons you mentioned. I've found it best to think of Python 2 and 3 as totally separate languages, so I consider it a good thing that the binary name python3 is unambiguous in all contexts.
AFAIK the packages in Debian/Ubuntu world should only be removed on major OS release (Debian 9 -> 10, Ubuntu 22.04 -> 22.10, etc).
I think that if you upgrade the OS by just changing repo URLs in apt config, the old packages will stay installed - so it will be just like in Arch situation described by the author.
Ultimately all sets of packages are a consensus - either a company says "we only use these versions of these languages and libraries" or it's a whole community. (This honestly beats the laissez faire approach which always blows up somewhere)
It's something companies shoukd consider doing internally as well - this API is supported at this version etc. It's easier to do explicitly than implicitly (large companies usually have internal SLAs and actual written docs)
I think the point I am making is good deprecation is part of good contracts.
Also notable is that such a deprecation notice is not fatal: usually one maintainer or group of maintainers have decided - but that's based on their own view of needs vs headache.
A user can easily (often) continue maintaining a local copy - just for their local habit. First just with the current version of the software. And nothing prevents them from taking over as public maintainer for Gentoo. Either as a mainstream package or in one of the many unofficial repositories. This is all helpful as package system features.
> On Arch, packages just kinda vanish from the repos it seems like.
Arch isn't designed to hold your hand, it encourages users to do their own research and due diligence, it expects responsibility from their users.
Arch Linux is nothing more than pacman and makepkg, both are designed to give you bare-bones packaging capabilities, how you use those tools and manage your system is up to you.
pacman has the -Qm option which will show you packages that are no longer in the database, so you very much can do the same, i.e. plan ahead.
A major difference of portage (in contrast of pacman) is that portage has a lot more abstractions (USE flags, EAPI, news, etc) but those come at the cost of complexity.
Yeah and key here is that there's nothing to stop you from cloning the repo for a package, checking out an older revision, and running makepkg (granted, it's not guaranteed to work but...)
I sometimes half-joke that Gentoo is the only Linux distro I can "tolerate" using. Mostly as I've always been the affectionate butt of jokes from other Linux using friends
After using Gentoo for about 15 years at this point every time I try to use another distro it just feels deeply unintuitive and backward.
Some of the examples I often cite:
If I want a package in Gentoo, I just run "emerge -av [package]" if need be I can alter its USE flags under /etc/portage/package.use/[package-name] and get exactly the features I want and need, and nothing else.
If that package doesn't exist, Gentoo's portage has a system where it suggests "similar" sounding packages. Like if you try to emerge "firebox" instead of "firefox" it will offer it as a correction
If I want a package in Debian/Ubuntu conversely, I type "apt-get -y install [package]" and sometimes find that oops that's not the package I want, or that package doesn't exist under that name!
Then I try searching for that package via aptitude, getting a litany of "libpackage3/5/7/9" or libpackage-something-something-dev libpackage-something-something-doc libpackage-something-something-headers and so on. It's all just very messy. There's also rarely any description as to what the package is without googling it beforehand
For many years I used Chromebooks as my portable Linux PC of choice. My rationale at the time being that Google mandated no "binary blobs" in the kernel and that all hardware support must eventually land in the upstream kernel. Along with hiring the entire Coreboot team these made extremely attractive (albeit cheap and disposable) laptops
Some of the hardware support (keyboard backlighting, trackpad etc) weren't yet in the mainline kernel. On a binary distro I would have to source out (or build my own) patched kernel manually to add this hardware support
Gentoo due to being source based provides an entire mechanism for just this, under /etc/portage/patches
This feature isn't exclusive to the kernel either. Any package you want on a Gentoo system can include any number of custom patches you desire as a user. I've used this feature additionally for enabling things like Intel ARC GPU hardware encoding support under ffmpeg while it was still in development
Gentoo's biggest draw for me however is its philosophy and dedication to "choice". Not choice in the traditional sense of "we have lots of desktop environments to pick from". Choice is etched into Gentoo's very bones by its nature as a source based distribution.
When briefly setting up a temporary NAS at a friends house I opted to simply use Fedora, thinking it would be easier than spinning up a full install of Gentoo for such a short-lived purpose
Installing Fedora and Samba I grabbed my smb.conf from home and used it as a template to set up the NAS. After starting it up I found no success in writing to the drives. I had correctly configured them in /etc/fstab, added the appropriate users and on a whim even tried chmodding the mount point just to rule that out
After a lot of googling it seemed that Fedora's SELinux was the culprit. I'm not interested in debating the merits of its inclusion or not, indeed I agree SELinux is a powerful security toolkit.
I bring it up purely to highlight Gentoo's difference in ethos and why I'm personally drawn to it. Gentoo never "does" anything for you on its own. It does not try to make any assumptions or guess your intentions as a user. I liken Gentoo to being given a bucket of Lego bricks. You have a vision in your head for what you want your system to do, and how to do it. So you build it to those specifications brick by brick.
> Gentoo's biggest draw for me however is its philosophy and dedication to "choice".
Same. I remember when I was going through the install handbook its three stated "design principals [sic]" of openness, choice, and power [0] spoke to me.
> I liken Gentoo to being given a bucket of Lego bricks.
I recall seeing some comment (might've been ascribed to Daniel Robbins, not sure) about how "Gentoo was created to be LFS for humans."
> If that package doesn't exist, Gentoo's portage has a system where it suggests "similar" sounding packages. Like if you try to emerge "firebox" instead of "firefox" it will offer it as a correction
This exists in Ubuntu/Debian - if you type `firebox` you literally get:
$ firebox
Command 'firebox' not found, did you mean:
command 'firefox' from deb firefox (1:1snap1-0ubuntu2)
Try: sudo apt install <deb name>
> After a month though, the package will get removed from tree along with the package mask (no need to mask a package which isn’t there anymore).
Does this mean that the package manager will just remove the package on its own automatically? If so, I take great exception to that. Removing packages like that should always involve overt user interaction.
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.
If you go to an earlier commit here, you can find earlier versions: https://github.com/gentoo/gentoo
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.
Are you using Debian now?
yep, work machine, with a nvidia card...
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!
Gentoo was my first proper Linux distro that I started using over a decade ago. As the time has gone by and I ended up using other distros for other purposes, I got exposed to the ways the other distros do things... which I often found to be unintuitive or confusing compared to Gentoo. It made realised just how lucky I was that I started off with a distro that pays such close attention to detail to so many things - like the one in the post. Gentoo was definitely one of the main reasons I found so much joy in Linux and resulted in the career that I have today.
Gentoo was how I was introduced to Linux, too.
A Dutch friend on a filesharing IRC network walked me through an install process on my old laptop, via Skype, throughout an entire evening and some of the night. I remember how we went through one-by-one enabling certain kernel modules and reading the descriptions of what they did.
A comment I could have written word for word.
Not hyperbole to say that Gentoo set the course of my life. I don't use it anymore, but I'll never forget my time with it.
Long may it continue.
Here another one o/
I got my first job in the web world because I was using Gentoo at home, and that totally defined my career as well. The day I build again a desktop computer, I think I'm going to install it again (although waking up at 4AM to check why the kernel or Konqueror weren't compiling and fixing the flag or dependency issue is certainly something I will not do again)
My old Athlon could write books about failed compilations and 13 year old me fudging up every config file.
Plenty of arguing with my parents to let me leave the computer on overnight to finish compiling KDE 3 on a Pentium 4.
What do you use now? Why’d you change?
Fedora. I use Linux for work and have kids, don't have the luxury to tinker as much as I used to.
You may or may not like FreeBSD. A lot of the packaging concepts in Gentoo came from ports (hence the name portage). FreeBSD has binary or source packages that can be mixed, is stable, and is slower moving than Linux (in a good way).
Having extensively used Gentoo on the desktop (laptop, even!) mostly just makes me grumpier at all the time and money we waste doing shit our OS could do for us with way less effort. But nobody likes those solutions these days, they want to re-invent system services as fragile, fiddly crap with a Web dashboard.
It’s handy to know because sometimes I can save day, but mostly just means I can name the older, better thing we’re spending a dump truck of money to do the hard, worse way.
I think a lot of the reason why I don't use Gentoo anymore is because the time I have to waste when I have to compile Chrome from scratch and wait two hours vs. just installing a precompiled .deb archive. :)
I'm pretty certain you could just select the binary version of Chrome. Most large apps have a precompiled package: LibreOffice, Firefox...
There is no source version of Chrome since it's closed source. I assumed GP meant chromium. A while back there was a chromium-bin for a short period, but it seems to have fallen out of maintenance and is now removed.
Oh man, I always install binary chrome-stable. Rust is another I don't enjoy building, so bin package there as well. But god forbid one of LLVM, QT and glibc chewing up all my CPU time every few months.
Just as a data point, I have a new AMD 7840U-based laptop and I built rust in 38 mins, and firefox in 27.
Truthfully, I never actually got to the rust build portion of the install. Rust required it's own patched version of LLVM to build, and I stopped there since I felt it was not worth compiling both, just for the one.
I recently installed Gentoo for the first time and I like it too. The installation process may be long but I think that's actually a strength if you're part of the target audience. The handbook is not just an installation guide but also an effective introduction to how Gentoo works and it just feels a bit more transparent to use.
I don't even use Gentoo, but I still extensively use its wiki. The Gentoo Handbook is the best documentation I have ever encountered.
Started off with CentOS and I'm still recovering.
> So I won’t get the helpful message if I happen to go more than a month between system updates. Which I think is a fairly generous window.
Gentoo was my first Linux distro and it was cool.. It definitely taught me a lot about app building. But the expectation that every machine needs to be continuously updated at least once per month is what caused me to go to Debian. You have that server which just works and you haven't logged in there for three months.. or a laptop which you only use for travel? Prepare for broken automated updates and careful package rebuilding in just the right order.
Yeah, this is nice. I bet something like this could easily be brought to systems like Arch/Pacman and NixOS/Nix if someone wanted to champion coming up with an implementation for those systems.
(Actually, this is definitely doable on Nix, since there are mechanisms like "insecure" packages, but 1. I dunno if there's any for this situation (block package without explicit confirmation because it's not maintained) 2. I don't think there's any policy for this, but it would be nice if there was at least a procedure for people who wanted this kind of deprecation. It's also a bit different on Nix since it is not a rolling release distribution.)
NixOS recently introduced "problem" infrastructure to deal with such problems more gracefully and explicitly:
https://github.com/NixOS/rfcs/blob/master/rfcs/0127-issues-w...
Completely agree. This seems a really nice approach in Gentoo. Am a big fan of Arch but I was immediately thinking this would be handy there - I'm pleased with the engagement/responsibility that Arch encourages but this kind of thing is always catching me out and I pay a fair amount of attention to my installations!
> If I run any package manager operations between the mask date and one month after the mask date, I’ll get this comment telling me the package is masked. After a month though, the package will get removed from tree along with the package mask (no need to mask a package which isn’t there anymore). So I won’t get the helpful message if I happen to go more than a month between system updates. Which I think is a fairly generous window.
A month is generous? I mean maybe for my desktop machine. Certainly not for some headless file server.
If you're going more than a month without updating a server, then you should allow for the possibililty of a bit of downtime (or delay to read the docs) when you do get around to updating it. And since it wasn't clear in the article: removing a package from the portage repo doesn't cause the package to be automatically uninstalled from your system, and it doesn't cause the package to be ignored during dependency resolution.
More than a month without an interactive login, sure.
I agree, this is great. How does Debian do it?
One thing I liked about Ubuntu was how they handled the Python 2 -> Python 3 transition after version 2 was officially no longer supported.
`python` was then a non-existent command which would fail while python3 continued to work.
This way one would not accidentally run a Python 2 script which kind of worked with Python 3 but then failed under very specific circumstances, possibly even after running for a couple of days. Not even letting that script start in the first place directly after the distro upgrade was the correct thing to do.
There's a pretty popular `python-is-python3` package in Ubuntu which aliases `python` to `python3`. I used to install that in my dev environment setup scripts, but have since stopped using it for the reasons you mentioned. I've found it best to think of Python 2 and 3 as totally separate languages, so I consider it a good thing that the binary name python3 is unambiguous in all contexts.
It makes more sense to support that as an opt-in rather than making the default, I would think
AFAIK the packages in Debian/Ubuntu world should only be removed on major OS release (Debian 9 -> 10, Ubuntu 22.04 -> 22.10, etc).
I think that if you upgrade the OS by just changing repo URLs in apt config, the old packages will stay installed - so it will be just like in Arch situation described by the author.
For Ubuntu, their do-release-upgrade script asks you to remove packages that didn't make it to next release. https://askubuntu.com/questions/1392819/do-release-upgrade-h...
EDIT: you can find obsolete packages on your system using apt or aptitude https://askubuntu.com/questions/98223/how-do-i-get-a-list-of...
> How does Debian do it?
Debian guarantees than no package is removed from a release during its entire lifetime. This is why it's called Stable.
This can be extended to 5 years if you use LTS and up to 10 years if you use ELTS (but it's an external commercial service)
Then you are stuck with tutorials / instructions looking for python instead of python 3 until you just alias python 3 back to python.
Not just deprecation - there is so much about Gentoo's packaging tooling that is very nice.
It's a pity that other distros refuse to learn from it since they think its ideas must be limited to source-only distribution.
Ultimately all sets of packages are a consensus - either a company says "we only use these versions of these languages and libraries" or it's a whole community. (This honestly beats the laissez faire approach which always blows up somewhere)
It's something companies shoukd consider doing internally as well - this API is supported at this version etc. It's easier to do explicitly than implicitly (large companies usually have internal SLAs and actual written docs)
I think the point I am making is good deprecation is part of good contracts.
Developers: "I need this js library that will change API 18 times this month"
Also notable is that such a deprecation notice is not fatal: usually one maintainer or group of maintainers have decided - but that's based on their own view of needs vs headache.
A user can easily (often) continue maintaining a local copy - just for their local habit. First just with the current version of the software. And nothing prevents them from taking over as public maintainer for Gentoo. Either as a mainstream package or in one of the many unofficial repositories. This is all helpful as package system features.
> On Arch, packages just kinda vanish from the repos it seems like.
Arch isn't designed to hold your hand, it encourages users to do their own research and due diligence, it expects responsibility from their users.
Arch Linux is nothing more than pacman and makepkg, both are designed to give you bare-bones packaging capabilities, how you use those tools and manage your system is up to you.
pacman has the -Qm option which will show you packages that are no longer in the database, so you very much can do the same, i.e. plan ahead.
A major difference of portage (in contrast of pacman) is that portage has a lot more abstractions (USE flags, EAPI, news, etc) but those come at the cost of complexity.
Yeah and key here is that there's nothing to stop you from cloning the repo for a package, checking out an older revision, and running makepkg (granted, it's not guaranteed to work but...)
Exactly.
I sometimes half-joke that Gentoo is the only Linux distro I can "tolerate" using. Mostly as I've always been the affectionate butt of jokes from other Linux using friends
After using Gentoo for about 15 years at this point every time I try to use another distro it just feels deeply unintuitive and backward.
Some of the examples I often cite:
If I want a package in Gentoo, I just run "emerge -av [package]" if need be I can alter its USE flags under /etc/portage/package.use/[package-name] and get exactly the features I want and need, and nothing else.
If that package doesn't exist, Gentoo's portage has a system where it suggests "similar" sounding packages. Like if you try to emerge "firebox" instead of "firefox" it will offer it as a correction
If I want a package in Debian/Ubuntu conversely, I type "apt-get -y install [package]" and sometimes find that oops that's not the package I want, or that package doesn't exist under that name!
Then I try searching for that package via aptitude, getting a litany of "libpackage3/5/7/9" or libpackage-something-something-dev libpackage-something-something-doc libpackage-something-something-headers and so on. It's all just very messy. There's also rarely any description as to what the package is without googling it beforehand
For many years I used Chromebooks as my portable Linux PC of choice. My rationale at the time being that Google mandated no "binary blobs" in the kernel and that all hardware support must eventually land in the upstream kernel. Along with hiring the entire Coreboot team these made extremely attractive (albeit cheap and disposable) laptops
Some of the hardware support (keyboard backlighting, trackpad etc) weren't yet in the mainline kernel. On a binary distro I would have to source out (or build my own) patched kernel manually to add this hardware support
Gentoo due to being source based provides an entire mechanism for just this, under /etc/portage/patches
This feature isn't exclusive to the kernel either. Any package you want on a Gentoo system can include any number of custom patches you desire as a user. I've used this feature additionally for enabling things like Intel ARC GPU hardware encoding support under ffmpeg while it was still in development
Gentoo's biggest draw for me however is its philosophy and dedication to "choice". Not choice in the traditional sense of "we have lots of desktop environments to pick from". Choice is etched into Gentoo's very bones by its nature as a source based distribution.
When briefly setting up a temporary NAS at a friends house I opted to simply use Fedora, thinking it would be easier than spinning up a full install of Gentoo for such a short-lived purpose
Installing Fedora and Samba I grabbed my smb.conf from home and used it as a template to set up the NAS. After starting it up I found no success in writing to the drives. I had correctly configured them in /etc/fstab, added the appropriate users and on a whim even tried chmodding the mount point just to rule that out
After a lot of googling it seemed that Fedora's SELinux was the culprit. I'm not interested in debating the merits of its inclusion or not, indeed I agree SELinux is a powerful security toolkit.
I bring it up purely to highlight Gentoo's difference in ethos and why I'm personally drawn to it. Gentoo never "does" anything for you on its own. It does not try to make any assumptions or guess your intentions as a user. I liken Gentoo to being given a bucket of Lego bricks. You have a vision in your head for what you want your system to do, and how to do it. So you build it to those specifications brick by brick.
> Gentoo's biggest draw for me however is its philosophy and dedication to "choice".
Same. I remember when I was going through the install handbook its three stated "design principals [sic]" of openness, choice, and power [0] spoke to me.
> I liken Gentoo to being given a bucket of Lego bricks.
I recall seeing some comment (might've been ascribed to Daniel Robbins, not sure) about how "Gentoo was created to be LFS for humans."
[0]: https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Abo...
> If that package doesn't exist, Gentoo's portage has a system where it suggests "similar" sounding packages. Like if you try to emerge "firebox" instead of "firefox" it will offer it as a correction
This exists in Ubuntu/Debian - if you type `firebox` you literally get:
Even that is really a function of the shell and not the distribution itself.
Is that if you try to run the command, or install the package?
I do like that!
> After a month though, the package will get removed from tree along with the package mask (no need to mask a package which isn’t there anymore).
Does this mean that the package manager will just remove the package on its own automatically? If so, I take great exception to that. Removing packages like that should always involve overt user interaction.
No. It will not remove your local copy. But you can request it to do so.
I like how Dart does it with pub.dev
- packages are forever
- they cannot be deleted
* with rare exception ofc
Didn't even have to click the link, title said it all. I love brevity