[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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?


Reply to: