Re: Stateful system directories

[Giovanni Biscuolo <g@xelera.eu>]

[-- Attachment #1: Type: text/plain, Size: 3108 bytes --]

Hi Efraim,

Efraim Flashner <efraim@flashner.co.il> writes:

[...]

> I actually have the following snippet in my OS-config:
>
> ;; This directory shouldn't exist
> (file-system
>   (device "none")
>   (mount-point "/var/cache/fontconfig")
>   (type "tmpfs")
>   (flags '(read-only))
>   (check? #f))

yes! now that I read this I see how to workaround this class of
problems, thanks! 

This snippet IMHO deserves a section in the Cookbook: would you please
like to expand this in a proper section/subsection and submit a patch?

> While we work on fixing these

we in Guix you mean? shouldn't it be fixed upstream?

obviously we should help upstream as much as possible giving them
feedback; I don't know about fontconfig, but AFAIU Gnome upstream is
well aware (do I miss something?) of the problems with "statefulness"
compromising starting critical piece of system software like GDM and
*sysadmins* having to work that around deleting "system level"
directories and *each user* deleting one or more of their
.local/<something> files

how can Guix work on fixing this if not by providing workarounds in
system or user services (when will be available) that makes it easier to
sysadmins and users to fix that problems at a different level of their
systems?

to expand my reasoning just to give a little bit of context, I give this
other example: I use Nextcloud on NixOS (still not in Guix), it turns
out that there are a couple of issues that makes practically (I mean in
a practical way) impossible (AFAIU) using Nextcloud in a stateless way,
and there is no even a workaround; details here:
https://github.com/NixOS/nixpkgs/issues/49783#issuecomment-481350460
"[...] the underlying bug is a missing distinction between configuration
and state upstream…"

AFAIU this falls in the same class of problems as the Gnome one
described in the thread you are referencing to (also fontconfig?) 

so, in my POV, one of the interesting "side effects" (or probably main
effect? :-) ) of *using* distributions like Guix System or NixOS - which
promotes stateless configuration from the packages build phase up to
services provisioning [1] - is that users will be affected by this class
of problems while others simply ignores them because they prefer to use
an imperative way to manage their systems... and upstream does not get
enough pressure from its userbase to fix this class of problems

in my case, the Nextcloud problem described above is also refraining me
from investing some resources in trying to package it for Guix (also as
a service, obviously)

> does it make sense to modify some of these services to unconditionally
> recreate their home directories on boot/activation?

IMHO yes, it makes sense; unfortunately in cases like that described
above for Nextcloud, this could have destroying effects on the service,
so we cannot workaround :-S

Thanks! Gio'

[...]


[1] differences in approach to "stateless purity" apart, but they are
secondary in this context, IMHO

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]