On Thu, Sep 29, 2005 at 03:17:31PM -0500, Jeff Licquia wrote: > On Thu, 2005-09-29 at 02:31 -0700, Matt Taggart wrote: > > Steve Langasek writes... > > > It's ultimately Joey's call, but I think it would be far preferable to > > > try to fix these lapses in the core libs instead of shipping two > > > copies of libc and libpam with sarge r1. > > Well fixing the core would definitely violate the stable release criteria > > since it changes the ABIs. (at least that's my understanding, Jeff can confirm) > The PAM fix changes the behavior of the pam_unix module. The behavior > changed is not likely to ever be seen in the wild (basically, when a > blank username is submitted to session management, return an error > instead of PAM_SUCCESS), but it is a change. Certainly, however, this > could easily be fixed by patching the sarge pam module instead of using > the dynamic linker hack. > The glibc issues are numerous. The biggest problem involves POSIX > violations in NPTL 0.60, which evidently cannot be fixed in-place. > Also, there are several glibc 2.3.3 and 2.3.4 symbols that are now > required (more POSIX violations). > I have requested assistance with the glibc issues on several occasions, > and have been told that the best way forward is just to upgrade glibc. > So, I expect that the dynamic linker hack is really the best way > forward. Yeah, given that glibc 2.3.2 -> 2.3.5 includes internal ABI changes that break certain ill-behaved but nevertheless real-world applications, it's definitely not a good idea to change out the version of glibc in a point release. :/ -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature