On Thu, 30 Nov 2000, John N. Alegre wrote:

> Is there anyone who has taken RedHat 6.2 rpm and glibc to the 7.0 level using
> rpm.  If so please share the way you did it.  It might be necessary to build
> and install glibc from the tarball, upgrade rpm, remove the tarball files and
> then upgrade glibc with the rpm.

I'm coming into this late, but from the above paragraph I'd have to
answer no, I don't think anyone has done this, for two reasons that I can
think of immediately.

First, RedHat 7.0 uses rpm 4.0.x which uses a new database format. You can
upgrade your rpm, but you will also need to upgrade a number of libraries
that it depends on, including the db library that the new rpm uses. If you
go to

  ftp://ftp.rpm.org/pub/rpm/dist/rpm-4.0.x

You should find the packages necessary to do an upgrade from rpm 3.x to
rpm 4.x for RedHat 6.x. I have never tried this, so I can't testify to how
safe this is.


Your second problem is that glibc is the heart of the RedHat distribution.
Upgrading glibc from 2.1.x to 2.2.x without upgrading all the dependant
packages will have undesireable effects. The troubles you mention
between 5.2 and 6.x are probably a result of trying an upgrade from 2.0.x
to 2.1.x under similar circumstances.

Running 'rpm -q --whatrequires libc.so.6' will show you a list of all
the packages that *might* need to be upgraded. Upgrading any from that
list could require upgrading others. The net result is that you are
ultimately going to need to upgrade your entire installation from 6.x to
7.x.

[Note: actually running something on the order of

   rpm -q --whatrequires `rpm -q --provides glibc`

would be a more exact list of what depends on your existing glibc
installation. libc.so.6 isn't the only critical system file provided by
glibc. This line screws up because of the shell handling of the spaces and
stuff, but I'm sure with some shell magic you could generate a more precise
list.]

It pains me to point out that RedHat compiled the 7.0 glibc rpm against
kernel-2.4 headers, which further increases the likelihood of
incompatabilities.

Now I know that not *all* of the packages that 'rpm -w --whatdepends
/lib/libc.so.6' reports really need to be upgraded, but I don't think
anyone has documented which ones really do vs. which ones don't.


In short, if you want to play with the newer glibc 2.2 on a 6.2 install
and ou don't want to be dogged by 2.1 vs. 2.2 incompatabilities, I
recommend you DON'T use the rpm. The rpm will overwrite your existing
glibc and will break more things than anyone probably knows. If you can't
for whatever reason upgrade your system to 7.0, then I'd recommend
manually installing the source for the newer glibc and building it
being mindful to follow the instructions for installing multiple versions
of glibc on the same machine.

I'm not sure what your goals with the new glibc 2.2 are, but you might
also consider VMWare, userspace-linux, dual-booting or some other way of
making sure you have a complete and consistent glibc 2.2 system that won't
impact your glibc 2.1 system.

thornton



_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list

Reply via email to