bug#25852: Users not updating their installations of Guix

[Ludovic Courtès]

Tomáš Čech <address@hidden> skribis:

> On Tue, Mar 07, 2017 at 05:22:15PM -0500, Leo Famulari wrote:
>>On Tue, Mar 07, 2017 at 09:58:48PM +0100, Tomáš Čech wrote:
>>> On Tue, Mar 07, 2017 at 02:51:18PM -0500, Leo Famulari wrote:
>>> > This will take effect for the next release of Guix; it addresses a
>>> > problem that arises when somebody installs the binary release of Guix.
>>> >
>>> > I'm not addressing downstream packages of Guix with this commit.
>>>
>>> I'm sorry, I may not understand correctly your answer.
>>>
>>> Are you saying that situation when user freshly installs Guix on
>>> system with systemd (and thus has empty /gnu/store)?
>>
>>The "fix" I pushed will help anyone who does a new installation of Guix
>>on a Systemd or Upstart-based system, after the next release of Guix.
>
> Unless I'm missing some other commit, this won't work.
>
> When I perform these steps:
> 1] ./configure && make && sudo make install (or package installation)
> 2] mkdir /gnu/store
> 3] attempt to start daemon will fail as there is no guix-daemon in
>   @localstatedir@/guix/profiles/per-user/root/guix-profile/bin/guix-daemon
>   because there is no guix-daemon in /gnu/store
>
> Without daemon running you won't be able to make one in that location.

Good point.

To address this, we might actually need to revert
613d0895b92c677e0639d5e77c55043e38e020c8 (that is, keep @bindir@ in the
.service files), and instead replace @bindir@ with @localstatedir@ in
the recipe of the ‘guix’ package.

That way, the install-from-source scenario Tomáš describes above would
work, *and* the binary tarball would refer to localstatedir as Leo
intended.

WDYT?

Thanks,
Ludo’.