[digi_owl]

This oh so much include the upsurge in containerization and the quagmire that is Linux distro package dependencies.

First of all, containerization allows for static linking via other means. Meaning that as the container holds everything a program needs to run in exactly the right versions, it produce what is practically the same as a static binary with the linked libs compiled in.

Similarly, package dependencies are a quagmire because package A may want lib B, while C wants B+1. And B+1 introduce some subtle (or overt) change that makes it unsuitable for A. This then result in a game of telephone with package and file names to try to get both B and B+1 to exist on a system at the same time. But there are no real conversion for how to settle these conflicts so each distro have their own rules and procedures.

But really the distros are trying to make the best of a bad situation brought on by lib and program developer laziness. Laziness whereby they do not properly check breakages before shipping, or simply grab the latest and shiniest that gets their job done rather than track down the lowest common denominator that is suitable.

[lysium]

Containers are more than static linking. You can have multiple binaries, which is not really possible with static linking.

Your A and C package example are actually an argument for containers.

[digi_owl]

It may be used, by developers, as an argument for containers. But that is just the same old lazy devs being their same old lazy self. Containers are not fixing the underlying problem.