0 dkg@alice:~$ HOME=/nonexistent gpg-agent --gpgconf-list gpg-agent[599306]: can't create directory '/nonexistent/.gnupg': No such file or directory gpgconf-gpg-agent.conf:16:"/nonexistent/.gnupg/gpg-agent.conf verbose:8: quiet:8: debug-level:24:"none: log-file:8: default-cache-ttl:24:600: default-cache-ttl-ssh:24:1800: max-cache-ttl:24:7200: max-cache-ttl-ssh:24:7200: enforce-passphrase-constraints:8: min-passphrase-len:24:8: min-passphrase-nonalpha:24:1: check-passphrase-pattern:24: max-passphrase-days:24:0: enable-passphrase-history:8: no-grab:8: ignore-cache-for-signing:8: no-allow-external-cache:8: no-allow-mark-trusted:8: disable-scdaemon:8: enable-ssh-support:0: ssh-fingerprint-digest:24:"md5: no-allow-loopback-pinentry:8: allow-emacs-pinentry:8: pinentry-timeout:24:0: enable-extended-key-format:8: grab:8: 2 dkg@alice:~$
the result of returning a non-zero error code here is that gpgconf --list-options gpg-agent fails hard for user accounts with a non-existent homedir:
0 dkg@alice:~$ HOME=/nonexistent gpgconf --list-options gpg-agent gpgconf: running /usr/bin/gpg-agent failed (exitcode=2): General error gpgconf: fatal error (exit status 1) 1 dkg@alice:~$
This has the result of producing spurious warning messages for things like cronjobs that run as the user nobody, in situations where the system has some scripts that are expected to run at every user session that rely on gpgconf to determine what to do about the agent.
gpgconf should be robust enough that system-wide per-user scripts can run it without worrying about this kind of error. Otherwise, people are going to write system-wide per-user scripts that guess at GnuPG's configuration and behavior, rather than interrogating GnuPG's configuration through the preferred interface. That would be a bad outcome because all of those scripts would need to be updated if GnuPG's configuration and behavior were to change.