From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#25852: Users not updating their installations of Guix Date: Thu, 09 Mar 2017 16:42:30 +0100 Message-ID: <87bmta8nix.fsf@gnu.org> References: <20170223211156.GA24382@jasmine> <877f429kju.fsf@gnu.org> <20170306213434.GA25316@jasmine> <20170307063330.bhv2ugsvi3qeofu5@penguin> <20170307195118.GA30247@jasmine> <20170307205848.42w2pusavz37dgwu@penguin> <20170307222215.GA4046@jasmine> <20170308062542.hfypmvgp2o6il2xf@penguin> <87innid8e3.fsf@gnu.org> <20170309124229.dqlc4y3nxdg44yzp@crashnator.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cm0Da-000551-Pi for bug-guix@gnu.org; Thu, 09 Mar 2017 10:43:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cm0DW-0007eQ-IW for bug-guix@gnu.org; Thu, 09 Mar 2017 10:43:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:49665) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cm0DW-0007eM-Ea for bug-guix@gnu.org; Thu, 09 Mar 2017 10:43:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cm0DW-000131-8z for bug-guix@gnu.org; Thu, 09 Mar 2017 10:43:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <20170309124229.dqlc4y3nxdg44yzp@crashnator.suse.cz> ("=?UTF-8?Q?Tom=C3=A1=C5=A1_?= =?UTF-8?Q?=C4=8Cech?="'s message of "Thu, 9 Mar 2017 13:42:29 +0100") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: =?UTF-8?Q?Tom=C3=A1=C5=A1_?= =?UTF-8?Q?=C4=8Cech?= Cc: 25852@debbugs.gnu.org Tom=C3=A1=C5=A1 =C4=8Cech skribis: > On Thu, Mar 09, 2017 at 11:58:12AM +0100, Ludovic Court=C3=A8s wrote: >>Tom=C3=A1=C5=A1 =C4=8Cech 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=C3=A1=C5=A1 =C4=8Cech wro= te: >>>>> 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 Gu= ix. >>>>> > >>>>> > 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-dae= mon >>> 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 =E2=80=98guix=E2=80=99 package. >> >>That way, the install-from-source scenario Tom=C3=A1=C5=A1 describes abov= e 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=E2=80=99s probably the most important thing to address, and maybe we s= hould just forget the installed-from-source scenario (but document it). Thoughts? Ludo=E2=80=99.