Re: Introducing ‘guix pack’

[Federico Beffa]

address@hidden (Ludovic Courtès) writes:

> 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.

Packs share identical items, but it becomes essentially impossible to
remove one component out of many.

>> 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.

If you provide an archive such as
'guile-2.2.0-pack-x86_64-linux-gnu.tar.lz' reachable from the main
project page (especially without any warning about its intended
purpose), I bet that many peoples will install it and keep it.  If more
projects follow this example, we land to the above scenario where "rm
-rf /gnu" is not practical at all.

> 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.

This is clear to me, but there are many peoples who do not know about
Guix, or just don't want it.  They may still be interested in, say,
Guile 2.2.

With the 'pack' command it seems to me that Guix is being promoted as a
convenient development environment where at the end you can produce
binary bundles for distribution on any system that it supports.  But,
without providing at least a way to remove things, it seems to be
heading toward a dangerous direction.

Fede