From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Partelly Subject: bug#31907: New users get wrong/old profile path to guix after reconfiguring Date: Tue, 26 Jun 2018 14:45:47 +0300 Message-ID: <7D5D202B-781A-453A-B8A7-EA8DB38451C6@rdsor.ro> References: <022CFE10-F1D7-4C39-BBFE-473F82165F47@riseup.net> <87sh5hp2e0.fsf@gnu.org> <68c050778b26c874e04e2b34703cc363@riseup.net> Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52331) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fXpcX-0003vi-IF for bug-guix@gnu.org; Tue, 26 Jun 2018 11:11:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fXpcU-0008Et-Ac for bug-guix@gnu.org; Tue, 26 Jun 2018 11:11:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:56708) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fXpcU-0008EX-7Z for bug-guix@gnu.org; Tue, 26 Jun 2018 11:11:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fXpcU-0001JF-2Z for bug-guix@gnu.org; Tue, 26 Jun 2018 11:11:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <68c050778b26c874e04e2b34703cc363@riseup.net> 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: swedebugia Cc: 31907@debbugs.gnu.org Well, I wondered myself , and I was palning to test when I arrive home = today. But here is my take: 1. Premise: The system configuration is declarative. The declarative = state should be obeyed all times by the system 2. Implication: running a guix pull (or any other form of update) as any = user should not do anything to the guix stored in the system profile 3. Implication: updates of binaries in the system profile should never = be triggered by anything else than a guix reconfigure 4. Implication creating a new user should result in him seeing the base = state of the system , as left by guix reconfigure . It should never see = any version installed by any other user , root included. Now the issues: - Although the system is declarative, once you run guix config / guys = reconfigure you do not know the whole state of the system. Arbitrary = package versions are installed, and reconfigure will arbitrary update = those packages - the only way I seen to have consistent state is to lock all system = packages to a known version, and reconfigure should obey the lock. -running guix reconfigure is an issue at the current time. It is = because unless you lock each package @version (and I did not tried t = see if this works , a developer should confirm, or point to some good = workarround) adding a user, changing system configuration in some othe = small way=20 seems to trigger a rebuild - there is no guarantee that GuixSD will offer you a substitution = instead of building the derivation. Which if you are unfortunate to = update a package for which is not prebuilt substitution you will end up = looking at compiles wearing out your time.=20 -it may cause rebuild of critical system daemons, then, guess what, stop = them and reload. You have to be very careful and run dry builds to see = if anyone touches your system services, cause you do not want unplanned = service outage on a server.=20 -it reports success even if it fails to bring the system in the required = state. For example for me reconfigure failed to restart 2 services it = stopped, but it happily reported all went ok=20 - guix is still broken for me: reconfiguring the system results in build = errors sometimes. Also results in service errors , like home service not = being able to be restarted.=20 - guix pull inflicts all the wrongs of the universe upon its users. No = critical system utility should ever update itself from the bleeding edge = of a source repository. No matter how genius the developer is, it will = always break in too many ways. This is very bad practice. - guix reconfigure without locked packages does the same offense. will = try to update to a version of itself derived directly from development.=20= Tools: =20 - guix still lacks the tools to make sense as a user of what is = happening. For example, a guix diff which gives insight what exactly = triggered a rebuild. I could not find such a thing.=20 - other tools to keep under control the rebuilding happiness. I have = better things to do on my system then looking at walls of compiling , = donno for others. I want to add a user , not trigger compiles :P > On Jun 26, 2018, at 14:06, swedebugia@riseup.net wrote: >=20 > ou could ask: why care about the guix version in the system > profile at all? It is not used as soon as you run guix pull or = populated > the .config/guix some other way and adjusted the this to preceede in = the > PATH. > I care because if I create a new user via config.scm they by > default get access to an outdated guix when a newer is available. This > is in my view a bug.