cvs commit: src/include ctype.h src/lib/libcrypt Makefile src/lib/libskey Makefile src/lib/libutil Makefile

[Matthew Dillon]

:
:>     The real problem here is the PAM libraries.  There appears to be just
:>     one set of PAM libraries and that doesn't work when we have a mix
:>     of pre-library-upgrade and post-library-upgrade binaries that use them.
:>     We need to find a solution for PAM that allows both types of binaries
:>     to reside in the system at the same time.
:
:It's the same problem we have with the i18n support. I still think the best
:idea is to isolate the compatibility code under /compat/freebsd4.
:Each directory under /compat/freebsd4 should have an entry (.compat_replace :-))
:which decides whether it hides the "real" directory, so that e.g.
:/compat/freebsd4/usr/lib hides the "real" /usr/lib, but /etc is still visible
:by both. We can do that now based on the ELF tagging.
:
:Joerg

    Well, I think that might be too much of a hack.  I think all we really
    need to do is give the PAM shared library modules loaded via pam.conf
    a version (e.g. blahblah.so.X).  I think they are the only shared
    libraries we have which are unversioned.

    The pam shared library, libpam.so.X, is versioned already.  All we
    need to do is make it tag its own version number onto any PAM module
    it tries to load and the problem is solved.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>