From mboxrd@z Thu Jan 1 00:00:00 1970 From: Giovanni Biscuolo Subject: Re: Stateful system directories Date: Fri, 18 Oct 2019 10:05:33 -0000 (UTC) Message-ID: <87d0euwer8.fsf@roquette.mug.biscuolo.net> References: <20191018073501.GB1224@E5400> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:51837) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLP86-0000Q7-PH for guix-devel@gnu.org; Fri, 18 Oct 2019 06:05:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iLP84-000582-RV for guix-devel@gnu.org; Fri, 18 Oct 2019 06:05:06 -0400 Received: from ns13.heimat.it ([46.4.214.66]:40178) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iLP84-00057f-HZ for guix-devel@gnu.org; Fri, 18 Oct 2019 06:05:04 -0400 In-Reply-To: <20191018073501.GB1224@E5400> Date: ven, 18 ott 2019 12:04:59 +0200 List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Efraim Flashner Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Efraim, Efraim Flashner 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!=20 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/ 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=E2=80=A6" AFAIU this falls in the same class of problems as the Gnome one described in the thread you are referencing to (also fontconfig?)=20 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 =2D-=20 Giovanni Biscuolo Xelera IT Infrastructures --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEERcxjuFJYydVfNLI5030Op87MORIFAl2pjksACgkQ030Op87M ORLt8A//RgqH4mQr2x+FlCNWlKdeqw79DmP/rX21K7cBCEVuo952dP+1jr2yNXNW q15zQ97VumYiWY2nG7a122g5FwHV70pxITJFXmArejByGRnhD3IkSn3ikA7crep1 32xPdxICt7FYxGT0yW63MCzd0AFDGsXqwWWXaB+j6+xGDqlY1XWQNkknbT3AIY9F xrsVxFsOLuNq4vuHp3yJnIvSFmLoYPtbSMXsKzoFsIy6ziVd3/qii+vNMZJzQL0g Do6vczqpVW4mTcbxxOc5UmnWiX0sp9gXMd9zIGGlH/x2SsUWjTw6OGUXKIKF3vlH im794xEvcTrtFo5I/cGCJB0nGzJ3ySUUhfY7tcaYfKC3B6Lj4jOFv0WEQWYfhy8u wGbu88N0jqXz2accFvW49GR5rr1yE1A28mqjSRxa5at+4hvffxsrgDOoMfQI2xgq KC4bfCvg8iMIIWcrDVl563jxmtKpe9pbQsG/EheH8qv9sdmku+XcbF2W31zaKAJQ 4Pj6KXXWhKcElaEMtYDMHID+zcJMnK30cjWJbdNryeeTg9SmCdiEsNbLVXvXG74r 7W7z/Ck8y7KQKV8o5+wDayJpUxhIrFqxgXI3Wf5dP99peZuhA36tF9J06AZ1zTom iV/WxcUuOYm5RJL78rERdHreVr6gY1khHwARroE75wP1EoHZmNg= =KQZm -----END PGP SIGNATURE----- --=-=-=--