[Maken]

I have run into this kind of package dependency lock-down sometimes when installing updated graphic drivers and build systems (usually from non-official repositories), and I have been able to solve it by reverting the problematic packages to older versions until I hit a well-formed dependency tree.

I only hit a similar problem in Windows once, when it hung up installing a new C++ runtime, and since then I could neither install another C++ runtime nor rollback it (restore system did nothing), resulting in applications randomly crashing or refusing to run because they were loading the wrong C++ libraries, and the only solution I found was reinstalling Windows again.

[mehrdadn]

Thanks! Yeah, this is a great follow-up to what I've been saying.

Right, Windows isn't perfect either. What it does have going for it, though, is that on Windows there are comparatively very few external shared libraries -- in fact, the only ones I can think of are in fact the C, C++, .NET, and SQL runtimes. So, as you confirmed, it means application updates rarely break your system globally. (OS updates can still wreck the system... but that's no worse than Linux distros in my experience... but let's not go on this tangent.) Of course, that comes at the cost of needing to rely on the vendor for updates to their uses of third-party libraries. It's understandable that not everyone would like this trade-off (though mine tends to prefer an out-of-date system that works than a patched system that's broken), so that part (kind of) makes sense, especially if people are extra-worried about security over productivity. The part I find mind-boggling is that Linux users are obsessed with package mangers for the initial installations themselves, not merely updating. Package managers seem (almost?) fundamentally flawed in that regard, and that's what baffles me. Do they really only ever want to install FOSS software blessed by their OS distro, and do they really think it makes sense for a system to break if they install anything unblessed? More power to them if they can live like that, but I can't.

In terms of the problem you faced, do you mind if I ask how recent of a Windows version it occurred on? (i.e. was it on pre-XP, XP, 7, 8/8.1, or 10?) One generic tip I do have is to use VirtualBox to boot into the host OS with an immutable virtual disk, make all the changes, and verify everything works correctly before doing it for real. It can come in handy when installing programs or updates that you suspect might be problematic. I can provide more details on this if you're interested; just let me know.

[Maken]

They are just different approaches, "bundle every library with the binary" vs "make every binary load the system library". And I think it's mostly a distinction of a system designed for final users (Windows), where your priority is making sure the program works with as little unknowns as possible, vs a system designed for production (Linux), where the people in charge wants to know exactly what is running.

Answering your question, I hit that problem on a Windows 7 machine, it was not a suspicious update, just the usual "install C++ redistributable 20xx to make this program work", but it crashed halfway for some reason. After a while I just reinstalled Windows (it was almost a clean install, so nothing starting anew was simply faster).

[mmjaa]

I'm guessing you don't know what "DLL hell" was.

>The part I find mind-boggling is that Linux users are obsessed with package mangers for the initial installations themselves, not merely updating.

Yes, because it keeps the system functional and operating and - if you use it properly - package management is a hellaciously great way to build a system.

> Do they really only ever want to install FOSS software blessed by their OS distro, and do they really think it makes sense for a system to break if they install anything unblessed? More power to them if they can live like that, but I can't.

Its your system, manage it how you like. But the default of 'safety and stability first' in a package manager is a feature, not a bug. Don't blame the tool if you don't know how to use it properly - its clear that you simply do not know how to use package management to your benefit. This doesn't mean package management is of no benefit; it means your basis of operating/administering the system is flawed. I would suggest this is due to your attitude more than anything else; its certainly not for technical reasons.

[mehrdadn]

> I'm guessing you don't know what "DLL hell" was.

I do. And like you said: "was". That's why I asked which version of Windows parent is talking abomut. Why are you bringing it up so many years later when you explicitly acknowledge it "was" rather than "is"?

> Don't blame the tool if you don't know how to use it properly

So many of you are baselessly claiming this yet none of you are telling me what I could have possibly done "improperly" to get into this mess. I told it to update everything. And there were no packages that had more updates... except these ones which wouldn't budge. If just telling my system to update and letting it do whatever it wants is "not using it properly" then -- to put it as nicely as I can put it -- there is a UI/UX problem. (Read: it would do a good job of explaining why a Linux distro isn't the main desktop OS, wouldn't it.)

[mmjaa]

When you say you told it to update everything, do you mean this:

    $ sudo apt update && sudo apt upgrade

FWIW, Steam has a long and chequered history with regards to dependency hell - and there are gotcha's with using it on 32-bit systems these days, so it could be that. Your package manager was protecting you from this issue, not limiting you, and I would suggest that the problem you ran into, was more related to Steams' requirements than to your package manager being borked somehow.

The reason you're getting so much push-back on this issue, I feel, is that there are far, far more benefits to package management than disadvantages, and in your special case you managed to get into a state that led you to the wrong conclusion, alas. Your package manager was protecting your system, as it is designed to do - what you needed to do was identify which package had the foul dependencies, and either decide to override the package manager, or uninstall the original app - which I believe was Steam.

Steam on Linux does have gotcha's - one of which, the designers of Steam also don't want to have to maintain a package repo or play nice with distro's efforts to keep peoples systems clean and well-maintained (too expensive to actually play along) .. so the fact that you were being tripped up by Steam, and subsequently blamed Linux-worlds' package management, is double-frustrating for those of us who have been using package management for decades and consider it one of the principle advantages to being Linux users, over the hell of Windows installation that has cropped the industry for decades.