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

Re: Please test gzip -9n - related to dpkg with multiarch support

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

Reply to: