From mboxrd@z Thu Jan 1 00:00:00 1970 From: myglc2 Subject: Re: The usability of Guix configurations Date: Mon, 06 Nov 2017 21:59:47 -0500 Message-ID: <86d14ux07w.fsf@gmail.com> References: <868tfjw4is.fsf@gmail.com> <20171106221621.GA2534@jasmine.lan> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36744) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eBu7F-0006sZ-V2 for guix-devel@gnu.org; Mon, 06 Nov 2017 21:59:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eBu7C-0006MF-39 for guix-devel@gnu.org; Mon, 06 Nov 2017 21:59:54 -0500 Received: from mail-qk0-x22b.google.com ([2607:f8b0:400d:c09::22b]:47400) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eBu7B-0006Lh-Vl for guix-devel@gnu.org; Mon, 06 Nov 2017 21:59:50 -0500 Received: by mail-qk0-x22b.google.com with SMTP id m189so13616442qke.4 for ; Mon, 06 Nov 2017 18:59:49 -0800 (PST) In-Reply-To: <20171106221621.GA2534@jasmine.lan> (Leo Famulari's message of "Mon, 6 Nov 2017 17:16:21 -0500") 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: Leo Famulari Cc: Guix-devel Please note: these replies are separated by topics in an effort to make the threads more topical ... On 11/06/2017 at 17:16 Leo Famulari writes: > On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote: >> My system recently broke when I did an upgrade. I reported what I >> thought was a bug (bug#29072) but it turned out that, because qemu >> package code had been moved, my system configuration had become broken >> ;-( [...] > As far as I can tell, the issue was related to the fact that you are > using Guix by building it from source and re-using the same build > directory, which may contain stale compiled .go files. In this case, > there was a leftover qemu.go, which shadowed the correct file, > virtualization.go. > > This is a useful development technique but not how Guix is supposed to > be deployed and updated. `guix pull && guix package --upgrade` is still > what we recommend and support. Yes, the initial issue as I reported and labeled it was caused by building from source and the fact that 'make clean-go' unexpectedly (at least to me) left stale files laying around. But if 'make clean-go' had nuked all the .go files as I expected, or if I had been using guix pull, I would still have experienced the configuration breakage caused by the qemu package being moved from ./gnu/packages/qemu.scm to ./gnu/packages/virtualization.scm which produced the error messages that befuddled me and which are the primary focus in this post. > If you want to deploy Guix by building it "by hand", I recommend using > a fresh Git checkout and directory each time you build it. That way, > you can be sure to avoid this class of error (stale module references > in leftover .go files), which is well-known to the seasoned Guix > developers but totally confounding for everyone else. That sounds really inconvenient and would not fit my mode of use (for details on my mode of use and how I see stale files, please this post: http://lists.gnu.org/archive/html/guix-devel/2017-11/msg00080.html Can you tell me what the benefit to developers are, if any, of keeping stale .go files around? TIA - George