David Dyer-Bennet wrote:

> Nathan Davis <davisn at mailandnews.com> writes:
>
> > David Dyer-Bennet wrote:
> >
> > > "Matthew S. Hallacy" <poptix at techmonkeys.org> writes:
> > >
> > > > On Tue, Aug 06, 2002 at 01:19:24PM -0500, David Dyer-Bennet wrote:
> > > >
> > > > > I'm upgrading to glibc 2.2.4-27 (including the usual -common and
> > > > > -devel; I don't use -profile).  In fact I have it running now.  rpm
> > > > > --verify reports all three are installed fine.
> > > > >
> > > > > However, if I try to reinstall glibc using "rpm -U --replacepkgs
> > > > > glibc-2.2.4-27.i386.rpm" I get "% post scriptlet failed", and if I try
> > > > > -common I get "% pre scriptlet failed".  When the first, at least,
> > > > > happens, *everything* stops working (well, presumably every program
> > > > > that depends on the glibc dynamic library; in fact a couple of
> > > > > staticly linked programs I found do still run).
> > > > >
> > > >
> > > > [snip]
> > > >
> > > > > I'm running now, but I believe my next upgrade will fail in the same
> > > > > way, so I'd really like to figure out WTF is going on and fix it.
> > > > > Anybody got a spare clue?
> > > >
> > > > Yes, I suspect you're using --nodeps and/or --force somewhere, that's
> > > > a bad idea, instead you should use apt, or up2date to upgrade all of
> > > > the packages that depend on $XYZ version of glibc at the same time.
> > >
> > > I didn't override any dependencies in the basic install.  I certainly
> > > have tried that when playing around trying to *recover* from the basic
> > > install, but the problem appeared without that.
> > >
> > > Given that *every* dynamic process died in the bad cases, I don't
> > > think it's a dependency of a particular program on a particular glibc
> > > version.  And the same dynamic binaries work when I copy over the
> > > binaries from my alternate root.
> > >
> >
> > Well, what version are you upgrading from?  If it's a different so number, then
> > binaries linked against the old version won't work with the new.  Given that
> > the installation was built against the old version, it is very likely that the
> > cause of your problem is a version mismatch.  You can try installing the new
> > version, instead of upgrading it.
>
> Old version was 2.2.4-19, if I remember correctly.  Might have been
> -14; anyway 2.2.4 still.
>

Okay then, it looks like my hunch about different versions was wrong.


>
> Is it actually possible to remove glibc and then install a new
> version?  If so how?  I thought the upgrade path was the only possible
> route, since pretty much everything, including the tools rpm calls,
> stop working when there's no glibc.
> --

I've only tried to upgrade glibc once, and I ran into problems because I used rpm
-U.  This caused the machine to essentially no longer boot (because the new library
had a different so-name, so there were dynamic linker errors).  After fixing it via
rescue disk, I believe I successfully "upgraded" by doing rpm -i.  At least I
remember this working for something (note:  may have had to use --force, I don't
remember).  Basically, two versions of the package were installed -- satisfying the
requirements for both old and new packages.  FYI, the -U (--upgrade) option is
really just a -e and -i, but done atomically from a dependency point of view.


>
> David Dyer-Bennet, dd-b at dd-b.net  /  New TMDA anti-spam in test
>  John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net
>         Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/
>          New Dragaera mailing lists, see http://dragaera.info
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shadowknight.real-time.com/pipermail/tclug-list/attachments/20020806/7b9a3267/attachment.htm