[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Introducing ‘guix pack’

From: Federico Beffa
Subject: Re: Introducing ‘guix pack’
Date: Sun, 19 Mar 2017 18:13:14 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

address@hidden (Ludovic Courtès) writes:

> Hi!
> Andy Wingo <address@hidden> skribis:
>> On Tue 14 Mar 2017 14:42, address@hidden (Ludovic Courtès) writes:
>>> If we remove /var/guix/profiles, users will have to actually type
>>> /gnu/store/asasdfadfgsadfa-profile/bin/guile.  This is not great, but I
>>> don’t know what else could be done.  We could profile a
>>> /bin/guile → /gnu/store/asasdfadfgsadfa-profile/bin/guile symlink, but
>>> perhaps that’s risky too.
>> As we were discussing in the channel, maybe it's OK for these binary
>> installs to claim "/opt/gnu".  Then we expose the profile in /opt/gnu,
>> so you would run Guile as /opt/gnu/bin/guile.  Additionally you could
>> actually build against that Guile, which would be pretty neat.  If the
>> user untars multiple guix packs, /gnu/store easily absorbs the union,
>> and /opt/gnu will adjoin any new profile directories/files and replace
>> any overwritten links.
>> We would have to make sure the union directory in /opt/gnu has all real
>> directories and only symlink files, as per the recent patch on
>> guix-devel.
> Commit 5895ec8aa234ec9a4ce68ab8f94e795807630168 takes a slightly
> different approach (it doesn’t use the union thing).
> You can run:
>   guix pack guile-next \
>     --symlink=/opt/gnu/bin/guile=bin/guile \
>     --symlink=/opt/gnu/bin/guild=bin/guild
> and that does what you would expect.
> In addition, /var/guix is no longer included by default.
> Let me know what you think!

Say, developer A distributes such an archive A and developer B
distributes archive B (a different program/library) and someone C
installs both.

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]