[PATCH 0/2] Respect XDG Base Directory Specification 0.8.

Note: Needs to be tested.

Bruno Victal (2):

home: services: xdg-base-directories: Set correct value for

XDG_STATE_HOME.

home: services: xdg-base-directories: Deprecate XDG_LOG_HOME.

gnu/home/services/desktop.scm | 4 +--

gnu/home/services/mcron.scm | 4 +--

gnu/home/services/pm.scm | 6 ++--

gnu/home/services/shepherd.scm | 4 +--

gnu/home/services/xdg.scm | 52 +++++++++++++++++++++++-----------

5 files changed, 44 insertions(+), 26 deletions(-)

base-commit: d92ec2f2812c76b23aab778e26708cf353542ae9

--

2.39.1

XDG Base Directory Specification 0.8 officially introduces the

XDG_STATE_HOME environment variable.

Fixes https://issues.guix.gnu.org/issue/61809.

(home-xdg-base-directories-configuration)[state-home]: Set default value according to spec.

Update field documentation.

(home-xdg-base-directories-service-type): Update service description.

---

gnu/home/services/xdg.scm | 22 +++++++++++-----------

1 file changed, 11 insertions(+), 11 deletions(-)

XDG_LOG_HOME is non-standard and log files should go to XDG_STATE_HOME

according to the XDG Base Directory Specification.

Fixes https://issues.guix.gnu.org/61809.

(home-xdg-base-directories-configuration)[log-home]: Deprecate and unset default value.

(home-xdg-base-directories-environment-variables-service)

(ensure-xdg-base-dirs-on-activation): Handle field deprecation.

(home-xdg-base-directories-service-type): Update description.

---

gnu/home/services/desktop.scm | 4 ++--

gnu/home/services/mcron.scm | 4 ++--

gnu/home/services/pm.scm | 6 +++---

gnu/home/services/shepherd.scm | 4 ++--

gnu/home/services/xdg.scm | 36 +++++++++++++++++++++++++---------

5 files changed, 36 insertions(+), 18 deletions(-)

On 2023-03-05 15:19, Bruno Victal wrote:

Ironically enough, it was my first idea for default value :)

Applied and pushed the first patch as

5c893787be78a79433fe1343f5b70cd647e8f667

Will think about the second one a little more and reply on that later.

--

Best regards,

Andrew Tropin

On 2023-03-05 15:19, Bruno Victal wrote:

If we deprecate XDG_LOG_HOME, maybe it's a good idea to make a helper

function, which can be reused across different services?

Also, how about appending /log subdirectory by default?

WDYT?

Overall LGTM, let me know what you think on a few comments above.

--

Best regards,

Andrew Tropin

Hi Andrew,

On 2023-04-07 09:45, Andrew Tropin wrote:

I'm wondering if this continued usage of XDG_LOG_HOME was a good idea,

maybe the service should just start using XDG_STATE_HOME as soon as possible?

(in which case, this patch will have to be reworked to reflect that)

This way we avoid introducing yet more code to handle deprecated code.

It shouldn't result in any kind of problems, XDG_LOG_HOME will still be set in the meantime

for scripts and code that happen to use it and are not part of (upstream) guix.

WDYT?

Cheers,

Bruno

On 2023-04-07 12:47, Bruno Victal wrote:

I meant introducing something like this

(define (get-log-dir)

(string-append

(getenv "XDG_STATE_HOME") "/log"))

and use it instead of

(or (getenv "XDG_STATE_HOME")

(format #f "~a/.local/state" (getenv "HOME")))

--

Best regards,

Andrew Tropin

Hi,

On Fri, Apr 7, 2023, at 8:46 AM, Andrew Tropin wrote:

Within the XDG directories, I think (unless perhaps you only use a single file) you are supposed to keep everything in a subdirectory named for your application (or with a well-known name for things shared among multiple applications). For example, on my system, I can find log files in "$XDG_DATA_HOME/akonadi/Akonadi.error", "$XDG_DATA_HOME/akonadi/Akonadi.error.old", "$XDG_DATA_HOME/sddm/wayland-session.log", and "$XDG_DATA_HOME/sddm/xorg-session.log". (Apparently SDDM and Akonadi haven't been updated to use $XDG_STATE_HOME.) I think Guix Home services should follow that convention, rather than putting all logs together in "$XDG_STATE_HOME/log/".

Perhaps my least-favorite part of the XDG Base Directory specification is having to repeat the default values so many times. But I understood the conclusion from https://issues.guix.gnu.org/56050#3 to be that Guix should be able to assume that the XDG variables are all explicitly set, either by Guix System or by the installation process for Guix on a foreign distro.

-Philip

On Sun Apr 9, 2023 at 8:09 PM BST, Philip McGrath wrote:

So it turns out Shepherd provides these gems squirreled away inside its

(shepherd support) module:

```

(define %user-config-dir

;; Default config directory if shepherd is run as a normal user.

(string-append (or (getenv "XDG_CONFIG_HOME")

(string-append user-homedir "/.config"))

"/shepherd"))

(define %user-log-dir

;; Default log directory if shepherd is run as a normal user.

(string-append (or (getenv "XDG_STATE_HOME")

(string-append user-homedir "/.local/state"))

"/shepherd"))

(define %user-runtime-dir

;; Default runtime directory if shepherd is run as a normal user.

(string-append (or (getenv "XDG_RUNTIME_DIR")

(format #f "/run/user/~s" (getuid)))))

```

Shepherd already provides us with a %USER-LOG-DIR variable :D

-- (

On Sun Apr 9, 2023 at 8:57 PM BST, ( via Guix-patches via wrote:

One thing I will note is that it might be good if (shepherd support) was one

of the modules imported into shepherd service gexps by default.

-- (

"( via Guix-patches" via <guix-patches@gnu.org> writes:

Apparently I can't read. This is *Shepherd*'s log dir, not a general

log dir variable. Oops :) I suppose that would be a good thing to add

to (gnu build utils), then...

On 2023-04-11 21:01, paren@disroot.org wrote:

That's right :)

Yep, I have the same idea.

--

Best regards,

Andrew Tropin

Hi Andrew,

Andrew Tropin <andrew@trop.in> skribis:

Could you take a look and apply it or close the issue?

Thanks in advance,

Ludo’.

On 2023-06-09 23:01, Ludovic Courtès wrote:

Sure, added this thread to my agenda for this week.

--

Best regards,

Andrew Tropin

On 2023-03-05 15:19, Bruno Victal wrote:

Hi Bruno,

Applied, added log subdirectory, pushed, thank you for working on it.

Hi Ludo,

WDYT about adding (home-log-dir) function to (guix build utils)?

So we can prevent copypasting the same code all over home modules.

Something like:

--

Best regards,

Andrew Tropin

Hi,

On Thu, Jun 15, 2023, at 5:35 AM, Andrew Tropin wrote:

I still think idiomatic XDG structure is NOT to have a "/log" subdirectory like this, as I explained in https://issues.guix.gnu.org/61982#7.

Aside from that, though, I thought the conclusion from https://issues.guix.gnu.org/56050#3 was that it is the responsibility of Guix System or the installation mechanism for Guix on a foreign distribution (e.g. "/etc/profile.d/zzz-guix.sh") to initialize all of the XDG variables, so code like this can use `(getenv "XDG_STATE_HOME")` unconditionally (or indeed with a checked assertion). Maybe there's some context I'm forgetting, though. I've been looking into these things again as I attempt to solve https://lists.gnu.org/archive/html/help-guix/2023-06/msg00031.html : I noticed in the attached environment variables that entries under /home/philip/.guix-home/profile/ are duplicated in many search paths.

-Philip

On 2023-06-15 14:09, Philip McGrath wrote:

With a brief look I didn't find information about this idiom in

specification, but you can highlight it with quote or link.

Anyway, I'm ok with storing logs in app subdirectory or "/log", not so

ok with storing them in the root of state home.

home-state-dir function can also be useful, which can later become just

(getenv ("XDG_STATE_HOME")).

--

Best regards,

Andrew Tropin

Hi,

On Thu, Jun 15, 2023, at 11:28 PM, Andrew Tropin wrote:

You are right that the idiomatic usage isn't made very explicit in the specification. In the specification itself, the idiom is implicit in the "Referencing this specification" section, which always uses a subdirectory:

(Obviously $HOME/.local/bin is a special case, since using subdirectories there would defeat the point.)

More than the text of the specification, I'd look at actual observed usage and documented best practices. The relevant Gnome Goal [1] (despite outbound linkrot) is consistent with every other developer guide I've seen in showing the use of subdirectories, e.g. in the Glib example code:

```

const char *cache_dir = g_get_user_cache_dir ();

char *mydir = g_build_filename (cache_dir, "myapp", NULL);

/* use it */

g_free (mydir);

```

(Glib now provides g_get_user_state_dir, too. [2])

The Arch wiki has a survey of XDG support status [3] that consistently shows applications using appropriate subdirectories.

[1]: https://wiki.gnome.org/Initiatives/GnomeGoals/XDGConfigFolders

[2]: https://docs.gtk.org/glib/func.get_user_state_dir.html

[3]: https://wiki.archlinux.org/title/XDG_Base_Directory

I'm not at all opposed to providing functions rather that using getenv everywhere: they could guard against typos, check invariants, and all the other usual helpful things. But---though maybe I'm missing some context---how often is it actually needed to pass these default values? As long as the upstream software supports XDG directories properly, I would think it should just do the right thing without having to pass a bunch of explicit configuration options.

-Philip