bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#25852: Users not updating their installations of Guix


From: Ludovic Courtès
Subject: bug#25852: Users not updating their installations of Guix
Date: Thu, 09 Mar 2017 16:42:30 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

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

> On Thu, Mar 09, 2017 at 11:58:12AM +0100, Ludovic Courtès wrote:
>>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?
>
> That will eliminate the problem introduced by the Leo's change but
> still keep original problem.
>
> To adress the latter I'm thinking I'll just make simple wrapper script
> which will check whether new version in root user's profile exists and
> run from @bindir@ if not.
>
> Not the nicest solution but it is safe.

Hmm, yeah, not great.

I think most people get Guix through the binary tarball though, so
that’s probably the most important thing to address, and maybe we should
just forget the installed-from-source scenario (but document it).

Thoughts?

Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]