From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thompson, David" Subject: Re: Add "guix update" command Date: Sat, 23 Jan 2016 14:37:46 -0500 Message-ID: References: <871tdycmtr.fsf@gnu.org> <87h9i4xng3.fsf@gnu.org> <20160123191146.52c824a8@alarmpi> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aN40L-0004bd-JQ for guix-devel@gnu.org; Sat, 23 Jan 2016 14:37:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aN40K-0000LX-7I for guix-devel@gnu.org; Sat, 23 Jan 2016 14:37:49 -0500 Received: from mail-yk0-x234.google.com ([2607:f8b0:4002:c07::234]:34258) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aN40J-0000L2-Vq for guix-devel@gnu.org; Sat, 23 Jan 2016 14:37:48 -0500 Received: by mail-yk0-x234.google.com with SMTP id a85so122452250ykb.1 for ; Sat, 23 Jan 2016 11:37:47 -0800 (PST) In-Reply-To: <20160123191146.52c824a8@alarmpi> 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: Fabian Harfert Cc: guix-devel Hi Fabian, This isn't the first time I've seen such a proposal, and while I appreciate the viewpoint, I don't think this would be a good decision for Guix and I'm fairly sure that the other developers agree. See below for further explanation. On Sat, Jan 23, 2016 at 1:11 PM, Fabian Harfert wrote: > 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. In Guix, we purposely do not distinguish between a user and a developer because we believe there is no distinction. We think the perceived line between user and developer should be blurred. Everyone should be enabled to hack on Guix, and introducing things that differentiate developers from "regular users" is counter-productive to our goal. > 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 additional complexity is one of the reasons why packages are not maintained separately from everything else. We know exactly what the outcome of such a scheme would look like because this is what Nix does. Nix, the package manager, exists separately from nixpkgs, which contains all the package recipes. This was deliberately avoided when the Guix project was started to avoid compatibility issues. By maintaining the packages separately from Guix itself, we must turn internal APIs into external APIs and become very concerned with backwards compatibility. We follow an approach similar to Linux. In Linux, kernel modules are maintained in the same source tree as the kernel itself. The reason for this is it allows the kernel developers to introduce changes to internal APIs and update *all* of the modules affected, together. This greatly simplifies maintenance and the ability to improve the software without introducing compatibility issues. Being able to break internal APIs when needed is something we simply could not afford to give up, at least not at this stage in Guix's development. Another reason is simply practical. Having patch sets that span multiple repositories is cumbersome. I know this all too well because I work at a company that has a lot of repository proliferation. It's not uncommon for a new feature to span 3 Git repos, and keep everything in order is a pain. > 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. A stable version of Guix would be nothing more (or less) than a branch in Git that received only critical security updates. > 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. This point is moot because it's already easy to include other package recipes via the GUIX_PACKAGE_PATH environment variable. See: https://gnu.org/software/guix/manual/html_node/Package-Modules.html#Package-Modules > 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. Services are at a higher level, actually. Services often use package objects in the g-expressions that define the service configuration. This is a good example of why Guix is a unified whole, and separating packages from the rest would only leads to strange incompatibility problems. Hope this helps! - Dave