Further to sam@'s comment at https://forums.gentoo.org/viewtopic-p-8792180.html?sid=3b503a27eeca2d556d02e8ae54e1d584#8792180. `ebuild pam_xdg-0.8.1.ebuild install` ran successfully on my AMD64 machine. But as i'm new to putting together new ebuilds, there's likely to be things i've missed doing! Reproducible: Always
Created attachment 863760 [details, diff] sys-auth/pam_xdg-0.8.1: New package
This is a pretty solid start. I assume this definitely works for you at runtime too (you've tried using the module)? As for the ebuild: >SRC_URI="https://ftp.sdaoden.eu/pam_xdg-${PV}.tar.gz" Use ${P} instead >+IUSE="doc" Drop, you're not using it anywhere. +src_compile() { + emake +} + Drop, this is the default definition. Also, you'll have to add yourself as a maintainer. We can't add new stuff as maintainer-needed. See https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/User_Guide#Proxied_maintainer_in_metadata.xml.
Created attachment 864003 [details, diff] sys-auth/pam_xdg-0.8.1: New package
(In reply to Sam James from comment #2) > I assume this definitely works for you at runtime too (you've tried using > the module)? i _believe_ it does, in the sense that XDG_CONFIG_DIRS, XDG_DATA_HOME, XDG_CONFIG_HOME, XDG_CACHE_HOME, XDG_STATE_HOME, XDG_RUNTIME_DIR and XDG_DATA_DIRS all get set to appropriate values. But i should describe my test setup, in case i've approached it the wrong way: * i edited /etc/pam.d/system-login, commenting out: -session optional pam_elogind.so and at the end adding: -session optional pam_xdg.so * i created a new user, logged in as that user, and immediately checked the output of `env`. i've now updated the patch to address the issues you raised.
Thanks, this looks almost perfect. Should we be calling `dopamd` to install a snippet into /etc/pam.d, or should we instead defer to user configuration and/or add a USE flag into pambase instead?
(In reply to Sam James from comment #5) > Thanks, this looks almost perfect. > > Should we be calling `dopamd` to install a snippet into /etc/pam.d, or > should we instead defer to user configuration and/or add a USE flag into > pambase instead? tl;dr: i'm not sure. :-) Here's what i've learned from various bits of testing: * Shells that utilise /etc/profile will source /etc/profile.env, which will set XDG_CONFIG_DIRS and XDG_DATA_DIRS after any setting of these vars done via PAM. * Despite having `-elogind` in my USE in make.conf (probably done early on in my Gentoo usage as i was doing some initial playing around, and then forgotten about), elogind is installed and being used (presumably because some hard dep is overriding the USE flag). What this means in this context is that there are actually *two* locations in /etc/pam.d where pam_elogind.so gets referenced: not only /etc/pam.d/system-login, but *also* /etc/pam.d/elogind-user. * Taking the preceding into consideration, the only XDG_* var set by pam_elogind.so that's *also* set by pam_xdg.so is XDG_RUNTIME_DIR, and they both set it to the same (i believe correct) value. Given the above, off the top of my head, it *seems* that unconditionally adding a conf snippet shouldn't cause any issues, and would avoid requiring extra work from users. But since i'm no expert on PAM, perhaps someone from e.g. the Security team might be able to offer their thoughts?
Created attachment 867542 [details, diff] sys-auth/pam_xdg-0.8.1: New package
