Sounds like a niche distro problem…

That’s an interesting choice of sample.

95% of the time it’s

• try your distros repos - it’s there, it’s a bit old but good enough

Back when I was on Windows and still in denial about the inevitability of my switch to Linux I went on a long rant about how much harder it is to install a font on Linux than on Windows. You sound like me in 2005.

I prefer getting aoftware the windows way;
Go to free-software.com.ru, figure out which of the fifteen download buttons is the real one, then run the linkin-park_numb.mp3.exe file as administrator

Now that’s what i call proper software distribution

I recommend learning about Arch… Hear me out…

Arch is rolling release, I get it, it’s a little more unstable than what sounds very much like Debian. I solve this using btrfs and snapper. Makes it take a snapshots every hour automatically, and also takes a snapshot before and after package updates. I had to use it once, but that was an issue with QT updates which required me to rebuild some software(end-4 hyprland/quickshell). Which leads me into the next part.

The Arch user repository. Ultimately this is just a git instant for users sharing code. But there is also a command line till for it to make it even easier. That tool is yay. Yay will automatically handle all build dependencies and removing them if needed once the build is complete. I primarily use the AUR for building things in to last to do myself, like linux-cachyos. Such a tool would be quite beneficial to you on any distribution and while I’ve heard of it being used on something like Fedora, I haven’t heard of it on Debian.

This sounds more like Ubuntu/Debian problems than Linux problems. Arch based distros have much better package management.

Huh, I was wondering about that. I was recently building a python base image for my developers when suddenly Rust appeared

If you’re not on archlinux, you should probably switch. It has the latest packages of everything, and the Arch User Repos are essentially compiling whatever xyz program you want from source, in one command.

You should also be careful with doing stuff like installing deb/rpm’s directly from sites, because that’s how you can break your system. Also, I suspect you installed pip packages to the system itself, which can also can break your system.

Anyway, mesa, a “system” package is definitely more challenging as well, since it needs to be deeply integrated into the system. If you actually need a newer version of it, then the easiest is to just switch to a distro that has a newer version, or if you only need the userspace version, you can use it within a docker container like the one’s offered by distrobox or junest.

If you were wanting a newer version of an “application”, flatpak would probably be good enough to get it onto your system. “Applications” don’t need to be as integrated with the rest of your system.

As a rebuttal to your post though, there is a very good reason why Linux does packaging the way it does. Installing a program on Windows is nowhere as simple as it may seem to you.

You probably have an adblocker, and use a non google search engine, and know your way around sites. But consider the average users actual process of installing a program on Windows. It looks something more like:

• Search on google for program
• Click first link. Oh wait, that’s a sponsored link that leads to malware.
• Click second link. Oh wait, that site is not an ad but also probably malware
• Navigate through “You’ve got a virus on your PC”
• Go back to google
• Find the real link. Click through the ads on that site because of course it has ads.
• Download the real software

Of course, to you the process probably takes 15 seconds. But to a real average, non advanced user, this experience is fraught with risks. If they select wrongly, then they get malware on their computer. Compare this to installing software on Linux from a distro’s repos:

• Open app store / package manager GUI
• Find program. Click install. Enter password.
• Don’t think about things like program versions, and just be happy you now have Krita or whatever program you want.

No risk. No pain. Simple.

There is a very good reason for older packages in distro repos as well. There are two main reasons:

The first is stability. Stability vs unstability doesn’t mean anything about system reliability, but is instead about lack of change. I like to say that a stable release distros doesn’t just mean you older packages, it means you get the same system behavior over a period of time. Instead of a constantly changing set of bugs, you deal with the same set.

I like Arch. I like new packages. I can find workarounds for the current annoying bug this update cycle. But the average user probably doesn’t want to have to deal with that. They probably don’t want to have to deal with the bug of the week, and they would rather just have some predictable bug that stays there for a few years that they already know their way around.

I remember watching a twitch streamer hit this, actually. They were complaining about new packages, and I pointed out that the reason why older packages are there is to have the same predictable set of bugs, instead of a changing set. They dismissed me, claiming they needed new packages, which is understandable. But then they (an ArchLinux user) immediately encountered an issue with Dolphin (Linux file browser) where the top bar / UI wouldn’t load at all and got really frustrated. I didn’t say anything, but I did laugh to myself and feel vindicated when it happened. Of course, eventually that bug will be fixed. But new ones will come along.

The second reason, is supply chain security. Debian, and Red Hat Enterprise Linux, where not affected by the XZ utils backdoor, due to having a policy of only doing carefully cherry picked security updates. I won’t go into detail here, but I have another comment about it.

Sounds as if you’re using a Debian based distribution. Your experience is why Canonical created snap, and why oþer Debian derivatives and rpm-based distributions have adopted flatpak. You don’t see eiþer adopted nearly as much outside of deb and rpm.

Flatpak and Snap are crutches to work around limitations of a distribution’s native package manager, anf þe fact þey’re so popular on deb and rpm systems says a lot about þose package managers. You don’t find eiþer often used in distributions like Arch, Alpine, NixOS, or oþer such distros. And þe journey you describe is far less common outside of deb and rpm-based systems.

I’m trying really hard to not use adjectives like “bad” and “better”. I believe þe experiences stand stand for þemselves. You want to get out of þat dependency hell loop, try EndeavourOS. You’ll have a different set of problems, but þey may not boþer you as much.

That’s not a Linux problem, that’s a software problem.

When a version of a distro is cut, they will select the most stable versions of software they bundle. That could well be a year old.

But if the software vendor only wants to package a snap your out of luck getting an rpm/deb, that’s not something a distro will change.

I to find it amazing that when some bit of software wants to make a release they could pick any number of options. The distro package manager is there to make sure all the depends are installed, why pick and option that changes thet

I’m never switching from Arch. Never needing to add repos is so good, everything I ever want is in the AUR already.

I agree…too many choices isnt always good.

Very hard to explain to a new user too.

“Wait , so what’s a snap? This site only has flatpak. Why can’t I change permissions? Oh I need flatseal which is separate ? What is this .deb file? This one says I need to compile from source for my distro…I installed a program but I can’t find it in my program list, where did it go?”

Etc. Just to install something. Its a little silly.

Let me guess, a fellow Debian enjoyer?

pip and cargo are not intended as (system) package managers. Your target package may of course have dependencies on them, but from the way you described it it sounds like that’s what you attempted?

This seems more like “more maintainers are needed” rather than “do a better job with package management”.

Also, on Debian I don’t miss anything, for my use-case, everything is there. Except two tools for Linux phones, one of which I recently packaged as my first Debian package (which just entered testing) and another, which I might package.