Re: The usability of Guix configurations

[myglc2 <myglc2@gmail.com>]

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