[ninkendo]

> Unless you're statically linking against distro policy they have dependencies on the particular version of the distribution they are built for.

The irony here is that we’re discussing flatpak/snap, which take the idea of static linking to the absolute extreme by doing something closer to a container where every dependency is part of the package. Maybe static linking being “against distro policy” is tossing the baby with the bath water by causing maintainers to reach to a much worse packaging method (snap) because the distro policy is just too obnoxious.

There’s no good reason you couldn’t just statically link (or relocatably copy) your dependencies into your .deb except the distro maintainers being purists. It would make the process of building a deb (or RPM or whatever) trivial because you’re using it as a dumb archive format for your build artifacts, similar to how a container works.

[ranger207]

Static vs dynamic linking is the core of the packaging debate isn't it? Like, distro maintainers say that dynamic linking is better because it lets them swap out libraries underneath the app in case of like security vulnerabilities and stuff. Devs don't like that because inevitably minor version changes break stuff unexpectedly, plus devs prefer to use shiny and new libraries that distros often don't have. Containers were IMO primarily a packaging and deployment solution, and container-style package formats like flatpak and snap are efforts to force distros to use static linking and stop breaking the app's libraries. IMO distro maintainers should realize that their advantages in security aren't as useful as claimed, and their claimed advantages in distro coherence are only relevant to maintainers, not devs and rarely users.

[JohnFen]

As both a dev and a user, I prefer dynamic linking over static linking. Usually.