On Thu, Feb 09, 2012 at 01:40:41PM +0100, Goswin von Brederlow wrote: > Steve Langasek <vorlon@debian.org> writes: > > - For many of these files, it would be actively harmful to use > > architecture-qualified filenames. Manpages included in -dev packages > > should not change names based on the architecture; having > > /usr/share/pam-config contain multiple files for the same profile, one > > for each architecture of the package that's installed, would not work > > correctly; etc. > Appropos pam config. Shouldn't that be arch-qualified (which includes > /etc)? No, it should not. These files are input for a central, shared, common PAM configuration meant to be usable by all services on the system. If you have a foreign-arch PAM-using service installed, but you don't have the foreign-arch versions of the PAM modules that are referenced by /etc/pam.d/common-*, that's a bug: the module packages should be installed for all archs, not just a subset[1]. The system-level authentication configuration should not vary based on the architecture of the binary! And if you happen to have a foreign-arch service for which you don't want to use the same set of modules, well, your service's config file doesn't have to include /etc/pam.d/common-* - but then that's a special case of a service that you don't want to use the common config, it's not something we should assume by default in multiarch. > Say I have pam modules for ldap installed for amd64 but not for armel? Why would you do that, except by accident? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org [1] As discussed previously on this list, we don't currently have a mechanism to ensure that these modules are installed for all archs, so this is not an unlikely bug. But in the worst case, it's also a very straightforward bug to fix by just installing the missing package.
Attachment:
signature.asc
Description: Digital signature