Steve Langasek <vor...@debian.org> writes: > On Thu, Feb 09, 2012 at 01:40:41PM +0100, Goswin von Brederlow wrote: >> Steve Langasek <vor...@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.
Ok, that is acceptable. We just lack any technical means to ensure this so far. Same problem as for input method plugins for example. >> Say I have pam modules for ldap installed for amd64 but not for armel? > > Why would you do that, except by accident? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aa4pe546.fsf@frosties.localnet