Re: Introducing ‘guix pack’

[Federico Beffa]

Andy Wingo <address@hidden> writes:

> On Mon 20 Mar 2017 15:14, address@hidden (Ludovic Courtès) writes:
>
>> Federico Beffa <address@hidden> skribis:
>>
>>> 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.
>
> Replying to Federico: These are the same considerations as with Guix
> fwiw, unless you remove old profiles and "guix gc".

There is a very big difference.  The Guix binary installation pack
does include the 'guix' command which allows you to remove stuff from
the store.  Any other pack not including 'guix' does not.

Suppose that Guix pack bundles become popular and compare them to,
say, Mac style archives.  Let's go through Ludovic's analysis:

1. Composability: With Mac bundles you extract the archive in a
   directory.  With Guix packs it's essentially the same.
   
   i. Sharing of store items: What are the chances that two
   independent projects will generate packs from the same git checkout
   (or guix pull)?  Pretty low.  Therefore the amount of sharing
   between different packs will be pretty negligible.

   ii. Adding a program. Mac style: you just extract it.  With Guix
   pack it's essentially the same, but it creates a manually
   unmanageable network of links which entangle all packs.

   iii. Remove an item: Mac style: delete a directory.  With Guix pack
   the choice is: delete everything or keep everything.  That is, you
   keep obsolete programs/libraries with security holes on your system
   ready for exploitation and unnecessarily filling your disk, or
   ... start from scratch.  Is this composability?

2. Security: Mac style bundles are problematic, but at least you can
   easily delete old stuff and replace them with updated versions.
   Guix packs are worse: delete everything or keep it all.

3. Reproducibility: As long as you carefully take note from which git
   checkout you generate a Guix pack, Guix packs seems to be superior.
   Oh, don't you also depend on upsteam published archives of every
   single package in Guix?  They sometimes disappear or are replaced
   in place with different archives and so, after some time, your
   carefully noted git checkout will not build anymore.

4. Experimentation: Guix is great for that, but packs?  Are they
   useful for testing on other GNU/Linux systems?  Maybe.  But aren't
   all Guix packages built in isolated environments anyway?  So, do
   you really need packs to test on other systems?  Maybe, but
   probably not.

Don't get me wrong, I find that Guix proper has many great features,
but pack is not one of them.  

I find very disturbing when peoples advertise things hiding half of
the story to make them appear better than what they really are.

Fede