<bavier1>sneek: later tell civodul yes, I've done quite a bit of work trying to get 'refresh -l' to be more reliable in the face of implicit inputs. Handling dynamically created packages (e.g. with package-with-python2) then became a critical issue. I haven't yet gotten a solution that's fast or accurate enough for my taste.
<chipb>I was playing around with using guix with a non-standard store/state location, as I won't generally have root access some machines I'd like to use it on.
<chipb>I figure...hey, just build it with distro libs, overriding state and store locations with configure flags, then use this binary to guix package -i guix.
<chipb>but the guix package definition hardcodes the configure flags to the standard location. failure.
<chipb>I can hack it easily enough myself, but I'm unsure if this would be considered a bug as far as guix is concerned.
<chipb>does anyone know of a rationale behind hardcoding store and state location rather than inheriting the values from the guix that's building the derivation?
<mark_weaver>chipb: interesting question. can you email email@example.com about it?
<mark_weaver>however, I should mention a few things: (1) if you use a different store location, you'll have to build everything yourself, which is quite a lot of stuff.
<mark_weaver>(since guix builds everything using its own toolchain, and uses *nothing* from the host system except the kernel, you have to start by building all of that stuff)
<chipb>yeah, I'll go ahead and type an email up. wanted a simple irc smoke test first. :-)
<mark_weaver>(2) running guix-daemon as non-root is not well-tested, and I would guess that a lot of our packages don't build properly outside of an isolated build environment, because some configure scripts look for things in standard places like /usr, and if it picks up any of that things will fail badly.
<mark_weaver>(3) the absolute pathname of the store needs to be very short, because otherwise you will run into problems because of the limited length of shebang strings in linux (the kernel)
<mark_weaver>e.g. many scripts will contain a shebang of the form #!/gnu/store/.../bin/foo
<mark_weaver>and linux (the kernel) has a rather small limit on the maximum length of that string.
<chipb>I had planned on running the daemon as root on one machine, actually. the plan is to sanely manage a fairly up-to-date tools directory shared via NFS without having to futz with building every little dependency.
<mark_weaver>I should also warn you that there are major performance issues associated with guix-daemon accessing /gnu/store via NFS.
<phant0mas>while libmachuser.so.1 does exist, gnu-make-boot-0 configure fails with /conftest: error while loading shared libraries: libmachuser.so.1: cannot open shared object file: No such file or directory