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 Thu, Nov 09, 2000 at 01:03:44PM -0800, Ulrich Drepper wrote:
> Ben Collins <bcollins@debian.org> writes:
> 
> > I'm not saying the soname should change. I'm saying that maybe a fall back
> > This is fixed by restarting the application, but that's a nightmare for
> > distributions concerned about upgrades (and asking the user to restart is
> > not the best face you want to show, being the Linux is touted for not
> > beeding reboots except for new kernel's).
> > 
> > Does this clarify?
> 
> Irrelevant.  The file names cannot be changed since this would mean
> you have to keep around all old versions for statically linked applications.

I didn't say that the current implementation should be disposed of, I
said it could have a fallback of this sort. That doesn't break anything,
not even static apps. It doesn't even break portability across different
distributions, or backward compatibility of old applications to a new
glibc.

All it needs is :

 dlopen("/lib/libnss_foo.so.2", ...);
 if fail
 	dlopen("/lib/libnss_foo-" MAJOR "-" MINOR ".so, ...);
 else
 	really fail;

Pretty simple.

> Deal with it.  There is no problem finding out which programs are
> affected and whether they are running or not.

a) Find the applications
b) Figure out the mechanism to restart them (assuming you find an init
   script that correlates to the daemon, which assumes it is under
   distribution control).
c) use that mechanism to restart it, if one is found

This is a lot more complex in practice than what your oversimplification
let's on. None of the above is automatic, nor very condusive to upgrades
in a distribution. Yes it can be hacked about on a per-distribution basis.
Yes we can all try to fix this problem ourselves, but that isn't very
helpful on a whole.

Glibc doesn't even need to create these files, since they only need to be
there when an upgrade happens, and only until they aren't needed
anymore (like the next reboot, or when the admin knows that all is well).
That end you wont have to worry about, it is something the distributions
can play around with. Giving a fallback does help, because it allows this
better approach.

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'

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