I like gentoo's package deprecation process

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.

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.

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

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

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.

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.

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.

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.

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.

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