RedHat is so medieval
So there's three systems. One of them runs CentOS 4, the other two run RedHat EL 4. One of the RedHats has been in use for quite a while, but the other two are freshly installed, and would need to have the same functionality as the first, but don't yet, mainly because they miss a number of packages.
So we do this.
[wouter@working-host ~]$ rpm -qa --qf "%{NAME}" | sort -u > working-host
[wouter@CentOS ~]$ rpm -qa --qf "%{NAME}" | sort -u > CentOS
Next, we compare the two:
diff -u working-host CentOS | grep '^-' | tail -n +2 | sed -e 's/^-//' > CentOS-missing
At this point, the file CentOS-missing contains some 403 lines. So how does one install packages on CentOS4?
[root@CentOS ~]# yum install $(cat CentOS-missing)
It starts thinking about it, then after several minutes comes back to me with "foo is already installed in an older version. I can't do what you're asking me"
[root@CentOS ~]# grep foo CentOS-missing [root@CentOS ~]#
In other words, it decided that, to satisfy one of the dependencies of one of the packages I'm asking it to install, it needs to have some other package installed, too, so adds it to the set. Then figures out that it's already installed, at an older version than what it was trying to install. Then bombs.
Okay Wouter, what were you thinking? Surely you can't expect a package manager to suddenly update packages when you ask it to install something else? That would mean upgrading and installing in the same command execution! Oh, the horror.
So, okay, we run yum update first.
Do you think that fixes it? Of course not!
It now comes back with... a message saying that a newer version of what we're trying to install is already installed.
Sigh.
So I'm now running 'for i in $(cat CentOS-missing); yum -y install $i; done' on this host. Since it takes yum several minutes to resolve dependencies, that means it's going to take a while to have it install 403 packages.
The not-yet-working RedHat 4 installation seems to have the exact same problem, except that up2date takes even longer to resolve dependencies, so we're not beyond the 'upgrade' step there yet. I'm sure it will come up with all kinds of other interesting failure modes. Luckily the RedHat-missing file is much smaller (83 packages).
How do RedHat users not eat their keyboard in frustration?
Note: yes, I'm aware of apt-rpm. Unfortunately, that is not supported on 64bit installations, because apt (in neither its dpkg nor its rpm variant) understands the notion of multiarch. At this time.
comm -23 working-host CentOS.Nice thing I discovered today. 1st information point: Without asking it to do so, the RHEL5.3 installation media installed a RHEL5.4 kernel for me. 2nd information point: I quickly browsed the release notes, taking a look at the nicely coloured info boxes. Well, they noted that the different drivers for Intels 3945 chips result in different device names along with some other boring stuff. So I assumed anything really interesting would have been covered. 3rd information point: We are using ethernet bonding. 4th information point: We don't use ipv6 (and currently can't for some reasons) 5th information point: the ipv6 kernel module is blacklisted, the relevant aliases set to off in modprobe.conf 6th information point: Despite 5, ipv6 is loaded on boot. WTF?
Ok, after quite some searching, assuming a misconfiguration on our side, I found a posting on the rhelv5 mailinglist, refering to the release notes. In a rather tiny (and in no way highlighted) note, they write that they updated the bonding driver to a new upstream, which unfortunately force a load of the ipv6 module with the bonding module now. So you need to set an option for the ipv6 module in modprobe.conf (which is new and would break the ipv6 module in older kernels). Great, I would have assumed that something existing being broken by the update would be prominent in the release notes.... I sooooo want Debian on our servers. Or at least some .deb based distro.
apt-rpm does actually support multiarch, that problem was solved back in 2006:
http://lists.atrpms.net/pipermail/atrpms-users/2006-February/004527.html
yum has come leaps and bounds over the years and on redhat/centos/fedora, the more recent versions are actually better than apt-rpm is these days.
I'd make sure that you have the latest version of yum available for your distro (the EPEL repos seem to have 2.4.3 as the latest version for centos/rhel 4) and also rpm and its associated libs. Once you've done that, do a "yum clean all" to get rid of your old headers and then run yum check-update and try and install the packages you wanted again (yum can actually install and pull in upgrades at the same time).
I reckon 95% of the problems I had with yum have been to do with corrupted cached headers and such (even though the errors don't seem to suggest anything close to that being the problem).
I just noticed one problem with your rpm commands from above:
[wouter@CentOS ~]$ rpm -qa --qf "%{NAME}" | sort -u > CentOS
should be:
[wouter@CentOS ~]$ rpm -qa --qf "%{NAME}\n" | sort -u > CentOS
unless the "\n" is getting stripped from your blogging system...
Yeah, I had that. I didn't actually copy-and-paste the commands, so that was an error in the blog
not that it matters much -- what matters is the problems I was facing. Thanks for you help, BTW; I'm sure it'll be helpful the next time I run into this kind of... <censored>.
Don't be fooled, apt-rpm does support 64bit just fine. Only when multi-arch was introduced this was true, but fixed not much after. This myth has been kept alive by the yum propaganda.
Unfortunately apt-rpm development is discontinued pretty much when the developer was hired by Red Hat
But I'll keep on using it until apt-rpm stops working and I am forced into medieval times 