> The fundamental issue is that you have independent actors that can't control what others do. Result is that sometimes software packages clash (namespace colli

> The fundamental issue is that you have independent actors that can't control what others do. Result is that sometimes software packages clash (namespace collisions, dependent libraries not in sync, incompatible licenses, etc). Yes, I agree. Where we are in disagreement is what the role of a distro is here. Distros are there to solve that stalemate in one way or another. In Code's case distro maintainers chose to mark these packages as conflicting. They could have changed namespace of one (or both) package[s]. As I have mentioned in reply to a sibling comment this is exactly the work distros are doing - solving the stalemate between upstreams. > The approach of using containers -- however flawed it is -- gets past the stalemate of independent actors in the software landscape being incompatible with each other. Sure, containers do try to get past the stalemate, but they try to solve a different problem - how to make conflicting dependency trees coexist. Containers can also fail to solve the stalemate. Sure, containers can isolate `/usr/bin/code` between containers, but contention on `/etc/code`, `$HOME/.code` or other static user data still has to be solved one way or another.