On Wed, May 24, 2017 at 11:37:27PM +0800, 藍挺瑋 wrote:
> Leo Famulari 於 西元2017年05月24日 00:16 寫道:
> > I'm a little confused: is there a situation where Guix is not installed
> > but '/usr/bin/guix-daemon' exists?
> 
> This can happen with source installation. 'make install' installs
> /usr/bin/guix* but not /var/guix. /var/guix doesn't exist until guix-daemon
> is started.

I see. We discussed this use case previously, which led to the change
which caused your issue:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25852#80

In short, we decided to break this for `make install` since we didn't
come up with a better solution at the time.

> > The path '/var/guix/profiles/per-user/root/guix-profile/bin/guix-daemon'
> > is guaranteed to exist if you followed the instructions in Binary
> > Installation [0], which is, as far as I know, the most common way to
> > install Guix on other distros. So, I think this path is appropriate for
> > the basic service file we provide.
> 
> I think you mean that the systemd service files included in Guix are only
> intended to be used with binary installation process. Do you mean that using
> them with traditional 'make install' installation is not supported?

It's de facto unsupported, since it's not working :) But, I think we
should address this use case, since it is causing problems for
downstream packagers.

> Yes, I am packaging Guix for Arch and Fedora, and I use the systemd service
> files provided by Guix in my packages since version 0.8.3. If doing so is
> never supported, I can make my own service files like what I did for version
> 0.6 to 0.8.2 and I think this bug can be closed.

I do think you should look into tailoring a service file to those
systems; you might be able to provide Guix on those systems in a more
integrated or idiomatic way.

However, we also try to offer upstream service files in the packages
offered by Guix, so I'd like to find a way to support both the binary
installation and `make install` use cases simultaneously.

Unless somebody proposes a fix in the meantime, I'll look into this more
closely before the next release.