This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: upgrade problem


On Fri, Nov 10, 2000 at 06:05:02AM +0100, Thorsten Kukuk wrote:
> On Thu, Nov 09, Frederic Lepied wrote:
> 
> > Ben Collins <bcollins@debian.org> writes:
> > 
> > > > 
> > > > It's a good proposition but it doesn't work because the old glibc
> > > > doesn't use this scheme and will load the libnss_foo.so.2 which points
> > > > to the new one...
> > > > 
> > > > That said, it can be done for the future...
> > > 
> > > Exactly...
> > 
> > So we have to change the sonames to be able to handle the upgrade...
> 
> Seems you really don't know that there are applications linked against
> libnss_* modules (Why do you think do we have /usr/lib/libnss_*.so files ?).
> What is the problem to update the glibc in single user mode or to reboot
> after an update ? It is the only save way to do it. Changing the soname
> will make your distribution incompatible to all other.

1) I don't plan on changing the soname (never have, I'm not stupid :)
2) Programs that actually link to libnss_*.so are not a problem since
   these modules are only loaded once at startup, and not unloaded (which
   is where the problem lies for other normal daemons).
3) Debian has always worked very hard not to force reboots on upgrades.
   This has not been a major problem at all. But, every major glibc
   upgrade requires us to restart all the daemons that make use of the NSS
   functions. I've been looking for a way to resolve this that:
   
   a) Doesn't break compatibility with glibc proper
   b) Will be accepted upstream
   c) Doesn't conflict with or hinder how glibc works now

To be honest at this point, if I can satisfy "a" and "c" in the above,
then I'll be happy. I can see most of the glibc folks don't really care
about this problem, mainly because they don't want to give the illusion
that in-place upgrades are a supported feature. I'm willing to accept
that and I can understand their reasons.

BTW, for the record, the patch I plan on using is attached. Note the other
half of making it work is in the package install/upgrade scripts (which is
of little concern to the list, so I wont bore anyone with it).

Ben

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'
--- glibc22/nss/nsswitch.c~	Fri Mar 31 15:38:32 2000
+++ glibc22/nss/nsswitch.c	Thu Nov  9 17:28:45 2000
@@ -333,9 +333,20 @@
 	      ni->library->lib_handle = __libc_dlopen (shlib_name);
 	      if (ni->library->lib_handle == NULL)
 		{
-		  /* Failed to load the library.  */
-		  ni->library->lib_handle = (void *) -1l;
-		  __set_errno (saved_errno);
+		  /* Failed to load the library. Try a fallback.  */
+		  int n = __snprintf(shlib_name, shlen, "libnss_%s.so.%d.%d",
+				   ni->library->name, __GLIBC__, __GLIBC_MINOR__);
+		  if (n >= shlen)
+		    ni->library->lib_handle = NULL;
+		  else
+		    ni->library->lib_handle = __libc_dlopen (shlib_name);
+
+		  if (ni->library->lib_handle == NULL)
+		    {
+		      /* Ok, really fail now.  */
+		      ni->library->lib_handle = (void *) -1l;
+		      __set_errno (saved_errno);
+		    }
 		}
 	    }
 

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]