Flatpack can be centrally managed, it’s just like a parallel distribution scheme, where apps have dependencies and are centrally updated. If a flatpack is made reasonably, then it gets library updates independent of the app developer doing it.
“App image” and " install from tarball" violate those principles, but not snap or flatpack.
Um, if it’s “parallel” (e.g. separate from the OS package manager) then it’s not centrally managed. The OS package manager is the central management.
There might be specific use cases where this makes sense, but frankly if segregating an app from the OS is a requirement then it should be fully containerized with something like Docker, or run in an independent VM.
If a flatpack is made reasonably, then it gets library updates independent of the app developer doing it.
That feels like a load-bearing “if”. I never have to worry about this with the package manager.
Define “the OS package manager”. If the distro comes with flatpack and dnf equally, and both are invoked by the generic “get updates” tooling, then both could count as “the” update manager. They both check all apps for updates.
Odd to advocate for docker containers, they always have the app provider also on the hook for all dependencies because they always are inherently bundled. If a library has a critical bug fix, then your docker like containers will be stuck without the fix until the app provider gets around to fixing it, and app providers are highly unreliable on docker hub. Besides, update discipline among docker/podman users is generally atrocious, and given the relatively tedious nature of following updates with that ecosystem, I am not surprised. Even best case, docker style uses more disk space and more memory than any other option, apart from VM.
With respect to never having to worry about bundled dependencies with rpm/deb, third party packages bundle or statically link all the time. If they don’t, then they sometimes overwrite the OS provided dependency with an incompatible one that breaks OS packages, if the dependency is obscure enough for them not to notice other usage.
Flatpack can be centrally managed, it’s just like a parallel distribution scheme, where apps have dependencies and are centrally updated. If a flatpack is made reasonably, then it gets library updates independent of the app developer doing it.
“App image” and " install from tarball" violate those principles, but not snap or flatpack.
Um, if it’s “parallel” (e.g. separate from the OS package manager) then it’s not centrally managed. The OS package manager is the central management.
There might be specific use cases where this makes sense, but frankly if segregating an app from the OS is a requirement then it should be fully containerized with something like Docker, or run in an independent VM.
That feels like a load-bearing “if”. I never have to worry about this with the package manager.
Define “the OS package manager”. If the distro comes with flatpack and dnf equally, and both are invoked by the generic “get updates” tooling, then both could count as “the” update manager. They both check all apps for updates.
Odd to advocate for docker containers, they always have the app provider also on the hook for all dependencies because they always are inherently bundled. If a library has a critical bug fix, then your docker like containers will be stuck without the fix until the app provider gets around to fixing it, and app providers are highly unreliable on docker hub. Besides, update discipline among docker/podman users is generally atrocious, and given the relatively tedious nature of following updates with that ecosystem, I am not surprised. Even best case, docker style uses more disk space and more memory than any other option, apart from VM.
With respect to never having to worry about bundled dependencies with rpm/deb, third party packages bundle or statically link all the time. If they don’t, then they sometimes overwrite the OS provided dependency with an incompatible one that breaks OS packages, if the dependency is obscure enough for them not to notice other usage.