DragonFly commits List (threaded) for 2005-06
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: cvs commit: src/include ctype.h src/lib/libcrypt Makefile src/lib/libskey Makefile src/lib/libutil Makefile
:
:> 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@xxxxxxxxxxxxx>
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]