Re: Please test gzip -9n - related to dpkg with multiarch support
Steve Langasek <vorlon@debian.org> writes:
> 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.
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
Reply to: