This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: RE: Redhat-list digest, Vol 1 #650 - 15 msgs From: Thornton Prime <thornton@yoyoweb.com> Date: Thu, 30 Nov 2000 09:09:02 -0800 (PST) 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 === Subject: Re: Redhat-list digest, Vol 1 #650 - 15 msgs From: Thomas Ribbrock <argathin@gmx.net> Date: Thu, 30 Nov 2000 17:11:07 +0000 On Thu, Nov 30, 2000 at 10:19:03AM -0600, John N. Alegre wrote: > Thank you Thomas! I'm trying, I'm trying... ;-) > 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. Hm... I hope I understand your problem correctly... How about getting the SRPMs and running a "rpm --rebuild" on them? At least with the rpm RPM, that should resolve the dependency on the newer glibc and result in an installable rpm RPM - and from there you should get things rolling. If that fails, you might need to edit the spec file, but unless there's an explicit "Requires" in there, you shouldn't have to. === Subject: Re: Chicken-and-egg - AGAIN From: John Aldrich <john@chattanooga.net> Date: Thu, 30 Nov 2000 10:10:00 -0500 On Thu, 30 Nov 2000, Thomas Ribbrock wrote: > On Wed, Nov 29, 2000 at 02:54:16PM -0500, William Stearns wrote: > > Simply do the upgrade, but upgrade them both at the same time > > with: > > > > rpm -Uvh glibc...rpm rpm...rpm > > Careful with that one! I haven't read the full thread (in fact I never > *got* the full thread - I only got about 20 mails on the list over the > past 24h...), but this command has potential for desaster. > The one thing you have to make certain is that the new version of rpm > you're trying to install is *not* using a new database format - 'cause > in that case a "rpm --rebuilddb" is needed to make things work properly, > and the command you listed might cause problems. > Such database format changes have happened a couple of times in the > past, e.g. somewhere between rpm 2.x->3.x and as well 3.x->4.x, IIRC. > This problem being discussed is on a RH 7 box, I think. In which case, it's an upgrade from rpm 4 to an updated version of RPM 4. However your cautionary words ARE something to keep in mind for anyone trying to upgrade from rpm3.x to rpm4.x. :-) === Subject: RE: Redhat-list digest, Vol 1 #650 - 15 msgs From: "John N. Alegre" <listhub@libros.andante.mn.org> Date: Thu, 30 Nov 2000 10:19:03 -0600 (CST) On 30-Nov-00 Thomas Ribbrock <argathin@gmx.net> wrote: > Message: 15 > Date: Thu, 30 Nov 2000 10:17:17 +0000 > From: Thomas Ribbrock <argathin@gmx.net> > To: ML-redhat <redhat-list@redhat.com> > Subject: Re: Chicken-and-egg - AGAIN > Reply-To: redhat-list@redhat.com > > On Wed, Nov 29, 2000 at 02:54:16PM -0500, William Stearns wrote: >> Simply do the upgrade, but upgrade them both at the same time >> with: >> >> rpm -Uvh glibc...rpm rpm...rpm > > Careful with that one! I haven't read the full thread (in fact I never > *got* the full thread - I only got about 20 mails on the list over the > past 24h...), but this command has potential for desaster. > The one thing you have to make certain is that the new version of rpm > you're trying to install is *not* using a new database format - 'cause > in that case a "rpm --rebuilddb" is needed to make things work properly, > and the command you listed might cause problems. > Such database format changes have happened a couple of times in the > past, e.g. somewhere between rpm 2.x->3.x and as well 3.x->4.x, IIRC. Thank you Thomas! This is the exact reason I have been screaming "has anyone actually used the fixes they are posting for this particular problem". To summarize some of the solutions that are incorrect. rpm -f is not the answer rpm --nodeps is not the answer using the interim version rpm 3.0.5 is not the answer Now it is true that rpm "somepackage" "someotherpackage" "somelastpackage" will work for packages that are mutually dependent. But when I tried this with rpm and glibc going from RedHat 5.2 > 6.0 the exact thing Thomas is pointing out happened and it took me a week to get the system back to where it was to begin with. 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. ===