[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#31907: New users get wrong/old profile path to guix after reconfigur
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 |
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
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.
-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.
-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
- 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.
- 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.
Tools:
- 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.
- 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, address@hidden wrote:
>
> 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.
> <sdb> 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.