Apropos of the discussion about removing default configuration from /etc. Upstream PAM now supports doing that. You can set up a vendor directory such as /usr/lib where pam.d and security live. I thought about doing that for Debian PAM, and have decided against. My rationale is that I actually think dpkg gives superior handling of upstream configuration changes to what we'd get with the pam vendor dir *in the specific case of PAM*. In particular, dpkg will let you know if the conf file has changed upstream and you have local changes. If we create a vendor directory, you will have to diff yourself to discover that. I do think that in the case of programs like systemd that do a complex merge of drop in fragments, the split of vendor dir from sysadmin dir makes a lot of sense. But for the most part PAM appears to just override on a file-by-file basis. And for that use case, I think dpkg's handling is at least as good. I appreciate others might differ. With dpkg's conffile handling you get better notification of changes but is it is hard to see at a glance which files might be changed. I am in favor of having a mechanism to easily reset the state in /etc. Personally I'm not convinced that deleting /etc is the best way for Debian to do that. I think we might be able to find dpkg-based solutions that are superior. If Debian does develop a project consensus behind minimizing /etc--especially if there is a policy recommendation or encouragement in this direction, then I'll revisit how we handle this for PAM. If Debian develops another approach for resetting local state, I'll be eager to look at that for PAM. --Sam
Attachment:
signature.asc
Description: PGP signature