From mboxrd@z Thu Jan 1 00:00:00 1970 From: Federico Beffa Subject: Re: Introducing =?utf-8?B?4oCYZ3VpeCBwYWNr4oCZ?= Date: Mon, 20 Mar 2017 09:09:31 +0100 Message-ID: <878to0z7wk.fsf@lupo.i-did-not-set--mail-host-address--so-tickle-me> References: <87d1dodcnb.fsf@gnu.org> <87k27tv5sp.fsf@igalia.com> <87r320m0u5.fsf@gnu.org> <87efy0t0tv.fsf@igalia.com> <87a88n7pwq.fsf@gnu.org> <8737e9dwb9.fsf@lupo.i-did-not-set--mail-host-address--so-tickle-me> <8737e827vv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cpsNm-0006ta-1k for guix-devel@gnu.org; Mon, 20 Mar 2017 04:09:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cpsNk-0001u5-Ut for guix-devel@gnu.org; Mon, 20 Mar 2017 04:09:38 -0400 In-Reply-To: <8737e827vv.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Sun, 19 Mar 2017 23:56:20 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Hi Federico, > > Federico Beffa 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=E2=80=99d get with Docker: the > unpacked items that are identical are shared, and those parts that > differ don=E2=80=99t 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=E2=80=99s a fine line here. In Guix circles we=E2= =80=99re very > good at explaining why =E2=80=9Capp bundles=E2=80=9D are a bad thing (com= posability- and > security-wise notably), and here that=E2=80=99s precisely what we=E2=80= =99re producing. > > The intended use case is mostly =E2=80=9Cone-off=E2=80=9D 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 =E2=80=9Crm -rf /gnu=E2=80=9D when they= =E2=80=99re 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