Re: [Fwd] Uploaded pam 0.66-1 (source i386 all) to master

[Ben Collins <bmc@it.larc.nasa.gov>]

On Tue, Feb 02, 1999 at 12:40:10PM +0100, Wichert Akkerman wrote:
> Previously Ben Collins wrote:
> > But the modules are distributed with and compiled against the main
> > library. If libpam1's module interface changes even in the slightest, I
> > don't want it being a problem for an upgrade path.
> 
> But the interface won't change: PAM is not a Linux standard, Solaris uses
> the exact same interace (in fact Linux PAM is derived from the Solaris
> documentation). I already asked the authors about that once..

The library might not change, but the module can. You could end up with
libpam0 and libpam1 installed using libpam1 modules. Now what if
pam_foo.so (from libpam0) had a special option it handled that is
deprecated in libpam1's version. A package should be able to depend on the
specific version of the module, but it is only possible to do this by
allowing more than one of the modules to be installed at once, without the
program being broken possibly.

This only affects modules included with the pam package. The only down
side is third party modules having to be installed in the versioned
security directory even tho they may work with a higher version. I see
this as a Good Thing tho since it will force the third party module to be
recompiled against the latest version, and this will make _sure_ that it
works with the latest library. I've made this easier for the package's to
work with by adding a file called MOD_VER in the security directory. The
only thing a third party module package has to do in the debian/rules is:

version=`cat /lib/security/MOD_VER'
module_dir=/lib/security.${version}

Since /lib/security is always linked to the latest version, they should
get the right one everytime they compile. I will cover all of this in the
HOWTO.

Also remember this only affects the major soname versions. 0.6, 0.7,
0.8... will all be considered the same thing as far as the version of the
module directory. We wont have to worry about this too often.

-- 
-----    -- - -------- --------- ----  -------  -----  - - ---   --------
Ben Collins <b.m.collins@larc.nasa.gov>                  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc.                 bcollins@debian.org
------ -- ----- - - -------   ------- -- The Choice of the GNU Generation