Ok many people today have seen bugs related to "openpam compatibility fixes".
I think it's better explain what's going on, why I'm filling them and why some 
of them are marked "openpam and amd64 compatibility".

For who doesn't remember, OpenPAM[1] is the PAM implementation used by 
FreeBSD, so also by Gentoo/FreeBSD project. OpenPAM is a base framework which 
actually doesn't provides modules, but just libpam and related utils.
It's lighter but usually compatible with sys-libs/pam (Linux-PAM actually).

Using PAM, many packages just uses pam_stack.so to provide the same 
authentication scheme as base login (system-auth), but this makes some things 
a bit complex. This because pam_stack.so is a non-standard module which is 
created by RedHat that gentoo "inherited" and which is used by many pamd 
files in the tree.

OpenPAM and Linux-PAM 0.78 provides the same functionality of pam_stack.so as 
"include directive", so something like

auth	required	pam_stack.so service=system-auth

can be changed in

auth	include	system-auth

and works fine both on >=sys-libs/pam-0.78 and openpam (G/FBSD).

I'm walking in the tree to fix packages which uses pam_stack.so and submit 
bugs for them, so to use include directive. Some of them just uses a pamd 
file which includes system-auth, in this case I reported them to use 
pamd_mimic_system which is a function I wrote in pam eclass[2], which is 
still not in portage as it's waiting for Azarah's review. This because using 
that function you save from have one more file in the tree.

Main issue with changing the files is that the minimum version required by the 
include directive for sys-libs/pam is 0.78, which is in ~arch for now. This 
means that packages needs to revbump to fix the dependency. The version 
requirement is already taken care by virtual/pam virtual which is provided by 
the right ebuilds.

Now, why amd64 is involved in this?
Many pamd files specifies the entire path to the modules they use, so for 
example, to use pam_stack, they use /lib/security/pam_stack.so .
This is valid now, but in no-lib32 profile for amd64, where /lib points to the 
32-bit version instead of 64-bit as it does now, it will fail.
Avoid using hte fullpath but just the pam module's name, fixes the problem 
both for amd64 and for openpam (openpam installs modules in /usr/lib).

This is ok for the pamd files in tree, for which I'll take care to report 
fixes to maintainers, but the problem is for packages which doesn't install 
the pamd file from the tree but from their own sources. In those cases, I 
can't do much, as I don't know all the packages in the tree to fix them, and 
I the ones I use I already take care of.

So if you are a maintainer who knows that your package installs a pamd file, 
drop a line to me (mail or irc) and I'll take care of looking at it for 
eventual openpam/amd64 compatibility fixes. This can also be done in a second 
moment for g/fbsd, but there can be problems with amd64, and fixing soon all 
the packages is still important.

Oh please note that not just pamd files needs fixes for G/FBSD, but also pam 
modules, so I may need to take a look also to some packages which installs 
pam modules. A full tracker for pam issues with g/fbsd is on bug #93119[3].

[1] http://www.openpam.org/
[2] https://bugs.gentoo.org/show_bug.cgi?id=93118
[3] https://bugs.gentoo.org/show_bug.cgi?id=93119
-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/