Hey there, Over the past month a few people (myself included) have been hit by the 'gotcha' of not running ./configure with "--localstatedir=/var". It doesn't say this in the documentation but I question whether not having it as /var is a sane default. I'm sure this is somehow tied to the conventions of /usr/local. Here's how this issue could be fixed, in order of usefulness:
* Change localstatedir to /var by default. This makes a lot of sense considering that's where it's expected to be. Even patches within Guix assume it's in /var , so installing and building Guix without localstatedir in /var would not only be a weird idea, it will actually *break* things. See avahi, xorg-server, findutils. * Put the localstatedir in /gnu. This is actually what Nix does, so I'm a little surprised as to why Guix has deviated from this practice. This will require updating all the patches to use /gnu/var as the localstatedir. What you get from this is the idea that the state is linked with the store (which it is!) and more importantly, comes in to the territory of GNU. * Instruct people to always pass "--localstatedir=/var" to configure. Sure, this could be done. But people are going to forget to do this and we'll have to explain on IRC to read the manual, then have them need to redo their entire Guix setup once they find something broken. Manually moving the state directory around is fragile enough since it involves moving symlinks around for profiles and isn't easily explained to people. More importantly, people are going to come away from their Guix experience with the feeling that something easily avoided has cost them a lot of their time, and they'd be right. The advantage this approach has is that localstatedir is configurable. Unfortunately, packages will still be broken. Perhaps it's time to substitute patch files too and introduce localstatedir as a build variable. * Do nothing. Software will still be confusing and debatedly broken. No doubt people will be having this discussion again. Cheers, Jookia.
