Re: Introducing ‘guix pack’

[Ludovic Courtès]

Hi Federico,

Federico Beffa <address@hidden> 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’.