From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fabian Harfert Subject: Add "guix update" command Date: Sat, 23 Jan 2016 19:11:46 +0100 Message-ID: <20160123191146.52c824a8@alarmpi> References: <871tdycmtr.fsf@gnu.org> <87h9i4xng3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52455) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aN2gt-0008Tb-J8 for guix-devel@gnu.org; Sat, 23 Jan 2016 13:13:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aN2gq-0007Uz-9b for guix-devel@gnu.org; Sat, 23 Jan 2016 13:13:39 -0500 Received: from mout.web.de ([212.227.17.12]:59598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aN2gq-0007Uv-0g for guix-devel@gnu.org; Sat, 23 Jan 2016 13:13:36 -0500 Received: from alarmpi ([79.202.73.223]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0MOzsZ-1aRjmz0pHj-006OFb for ; Sat, 23 Jan 2016 19:13:34 +0100 In-Reply-To: <87h9i4xng3.fsf@gnu.org> 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: guix-devel@gnu.org Hello, on IRC I already mentioned that, but there wasn't much resonance: I think for the purposes of non-developers the behavior of the "guix pull" command is too complicated. Normal users don't need a development version of the package manager, when they just want to get the newest package definitions to update their installed software. So it would be much easier and faster if there was a separate repository just containing the most recent package definitions. I propose to add a new command line option - e.g. "guix update" - fetching these latest package definitions and not doing anything else. They could be contained by a package whose definition is downloaded, for example "guix-packages". To avoid compatibility issues when there's a new release of Guix itself this package must be versioned equal to the Guix version numbers. I'm thinking of the following: The user is running Guix 1.2.1 and has installed the package guix-packages-1.2.1-4 containing the package definitions. Now he runs "guix update" and fetches guix-packages-1.2.1-5 with the new package definitions including the new Guix release 1.2.2. He now updates Guix to this version which has the new guix-packages-1.2.2-0 as an input. When he runs "guix update" again, guix-packages-1.2.2-1 is installed, which contains package definitions that make use of some new features. This would just be for the time between the Guix releases. I think we don't need support for older versions of Guix except from keeping the last guix-packages package, but we could also do some security or minor updates to the older package definitions which would provide users the possibility to use GuixSD as a stable distribution like Debian. Another advantage of the separation between Guix itself and the package definitions is that it's easy to provide an own or foreign guix-packages package which would promote the decentralization of Guix. Initially I thought of doing the same for service definitions except from the basic ones. But I think that version compatibility problems would occur more often because service definitions are at a lower level than the package definitions. In addition the notorious normal users won't change so much of their service definitions. Fabian