Hi Federico, Federico Beffa <be...@ieee.org> skribis:
> Say, developer A distributes such an archive A and developer B > distributes archive B (a different program/library) and someone C > installs both. Interestingly composability (what happens when you unpack both A and B on the same system) is better than what you’d get with Docker: the unpacked items that are identical are shared, and those parts that differ don’t collide. > Now developer A fixes a security hole and produces a new archive. How > can C remove the library with the security hole from his system? If he > just overlays the new version, the library with the security problem > stays on the system and could be exploited. Deleting everything is also > less than ideal. > > This seems to me similar to encouraging the much criticized practice of > bundling required libraries with your program. > > Maybe 'pack' could at least include a 'remove-myself' thing. Or have > you thought about the hole program life-cycle? Good question. There’s a fine line here. In Guix circles we’re very good at explaining why “app bundles” are a bad thing (composability- and security-wise notably), and here that’s precisely what we’re producing. The intended use case is mostly “one-off” packs where you just want people to easily test something, as opposed to putting it in production. This was the case for the Guile 2.2.0 release. In those cases, people would essentially “rm -rf /gnu” when they’re done. For code that is meant to be kept over time, I would recommend to either use Guix, or to include Guix in the pack so that people can eventually upgrade. Thoughts? Ludo’.