Thanks for your answers Josselin and Tobias,

(For the record, I just pinned all the commits from other channels in my
channels.scm and pulled guix with guix pull --allow-downgrades
--disable-authentication)

I finally managed to get the pam module to work but it eventually raised
more questions than expected.

Basically now the module starts well, but my shepherd service gpg-agent
doesn't (I guess because pam starts it, and that shepherd can't take
over). It's fine for the purpose I was installing pam-gnupg for (having
direct access to password-store passwords after login), but hinders the
rest of related activities (e.g. signing commits).

Above this question, I was wondering about the order of pam-modules
startup. A look at the manual pages and the examples for modules show a
clear hierarchy for at least a few modules (pam_unix > pam_loginuid >
pam_elogind > pam_gnupg for instance), which is not respected in guix's
implementation (pam_elogind > pam_loginuid > pam_gnupg > pam_unix).

Although it seems to work, is it normal / purposeful / without
consequences ?

If no, as a solution, maybe implementing a hierarchy might help. For
instance, something like :
1) Base modules (pam_unix, pam_env, pam_loginuid)
2) Modules added elsewhere with pam-root-service (pam_elogind, graphical
login managers modules)
3) Other modules (pam_gnupg, pam_motd...)

The last question I have is about the configuration of pam_gnupg. On the
official repo (https://github.com/cruegge/pam-gnupg), it seems that
there is a recommended configuration (e.g. setting the priority as
optional), which is once again not respected in the actual
configuration. I did add the few lines to address this (but is there a
reason why that is not the case ?)

I'm willing to help make these changes if useful and on the right track,
but I don't have much experience with guile.
Cheers,

Nicolas