I think this is an unpopular opinion, but I believe language package management systems try to solve solve the problem that has been solved by Linux distributions a long time ago, and they typically do it very poorly.

I suspect a prime reason is the absence of package management on Windows which a lot of developers (and users) use, and secondly the desire by developers to always use cutting edge library features when writing code, but nobody wanting to upgrade any dependencies after. There used to be a lot discipline about being compatible with many libraries versions IMO, nowadays people just specify the latest version of each library in their requirements.txt file (or equivalent in other languages).

I agree with you completely. Not only is security a problem, but mixed-language packages too. It's possible to put something like that in PyPI but it it's a huge pain (and the new setup.py replacements make it basically impossible).

> language package management systems try to solve solve the problem that has been solved by Linux distributions a long time ago, and they typically do it very poorly.

Yet, every main Linux distribution has its own packaging format (deb, rpm, etc) , package naming convention, dependency resolver, package release strategy (rolling, fixed, etc) , package build & deployment system (source, binary, per arch binary, etc), and package install peculiarities (custom, upstream focused, system wide, in a chroot, in a snap, etc), reproducibility constraints, etc...

So it's not like it's a _solved_ problem for Linux distributions.

Not to mention that most distribution package managers are system wide, while language package managers are often environment based.

> > language package management systems try to solve solve the problem that has been solved by Linux distributions a long time ago, and they typically do it very poorly.

> Yet, every main Linux distribution has its own packaging format (deb, rpm, etc) , package naming convention, dependency resolver, package release strategy (rolling, fixed, etc) , package build & deployment system (source, binary, per arch binary, etc), and package install peculiarities (custom, upstream focused, system wide, in a chroot, in a snap, etc), reproducibility constraints, etc...

> So it's not like it's a _solved_ problem for Linux distributions.

Just because someone reinvents the wheel does not mean it wasn't invented (solved before hand. I would also argue each distro package manager is miles ahead of any language one.

> Not to mention that most distribution package managers are system wide, while language package managers are often environment based.

That's the thing I was alluding to in the second part of my post, if developers would be more careful about backwards compatibility we wouldn't have to use environments. I do admit that packages for apps are more of an issue, it would be nice to upgrade those without having to upgrade the rest of the system.

> that has been solved by Linux distributions a long time ago

Certainly not. A recent example: I wanted to try a KDE distribution, so I installed Neon which has three dependency updaters by default: pkcon, apt, and snap. If I use Python or Node, then I usually need to use their distribution management systems as well.

Dependency management is one area that completely fragments Linux into different distro universes.

I am not saying Windows is better (it isn’t) but if Linux had solved the problem, then most of us would share one solution.

It's not impopular it's completely wrong to a point I can't comprehend. Have you ever seen the download page of any multi platform software ? It's one or 2 packages for windows, covering from win7 to win11, one or two for mac, and a dozen for linux and it cover only a very small subset of the distribs and their versions. Or more often they don't even care and provide only one ubuntu and red hat package and good luck to you.

The state of linux software distribution is completely abyssimal and ridiculous