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
