[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Introducing ‘guix pack’
From: |
Ludovic Courtès |
Subject: |
Re: Introducing ‘guix pack’ |
Date: |
Fri, 24 Mar 2017 10:56:03 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Hi,
Federico Beffa <address@hidden> skribis:
> 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.
That’s not true; you’d be likely to share glibc, gcc:lib, maybe GLib,
GTK+, etc.
> 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.
Don’t get me wrong, I agree! :-)
Again, I think packs are useful in some cases where the other options
are even worse, but I’m not advocating it as a general “solution.”
In the news entry online I tried to take into account the very
legitimate criticisms you made, but perhaps the end result didn’t make
it sufficiently clear that packs aren’t a general solution.
Ludo’.
- Re: Introducing ‘guix pack’, (continued)
- Re: Introducing ‘guix pack’, Andy Wingo, 2017/03/13
- Re: Introducing ‘guix pack’, Ludovic Courtès, 2017/03/14
- Re: Introducing ‘guix pack’, Andy Wingo, 2017/03/14
- Re: Introducing ‘guix pack’, Ludovic Courtès, 2017/03/14
- Re: Introducing ‘guix pack’, Federico Beffa, 2017/03/19
- Re: Introducing ‘guix pack’, Ludovic Courtès, 2017/03/19
- Re: Introducing ‘guix pack’, Federico Beffa, 2017/03/20
- Re: Introducing ‘guix pack’, Ludovic Courtès, 2017/03/20
- Re: Introducing ‘guix pack’, Andy Wingo, 2017/03/21
- Re: Introducing ‘guix pack’, Federico Beffa, 2017/03/22
- Re: Introducing ‘guix pack’,
Ludovic Courtès <=
- Re: Introducing ‘guix pack’, Ludovic Courtès, 2017/03/20
- Re: Introducing ‘guix pack’, Alex Sassmannshausen, 2017/03/20
Re: Introducing ‘guix pack’, Ludovic Courtès, 2017/03/16