Last weekend, I replaced a few parts in my pc. This meant I needed to upgrade my distro from ‘i586’ to x86_64. However, this is unfortunately not supported by the distro (RC1 gives weird error messages, the development one tells me it is not supported). The obvious solution is to do it manually.
RPM thought otherwise. It doesn’t let you install x86_64 packages because either it looks at the kernel, or the i586 rpm didn’t allow it. So I used ‘mc’ to install a x86_64 kernel (easier than extracting with cpio). Rebooted, and with the x86_64 kernel (nothing else upgraded), rpm still wouldn’t let me install x86_64 packages. In order to get around that, I manually installed the x86_64 rpm package and all it dependencies (note, this means that if you repeat this, your rpm will NOT work for a while). RPM has too many dependencies 🙁
After installing RPM, I noticed it had a few issues. Namely, it crashed when installing packages. This was due to the /var/lib/rpm files being architecture dependent. I first made a backup of that directory, then used a i586 db_dump (db42-utils) to make a dump of every file. Installed (cpio method) x86_64 db42-utils and restored the files from the dumps. After this RPM sort of worked (sometimes screwed up the rpm database, requiring a rm -f /var/lib/rpm__*). The corruption was solved eventually, but I don’t know how/why.
I then made a script to check for every installed i586 RPM, and upgrade to the x86_64 one (rpm -Uvh). The script knows to change ‘libfoo’ to ‘lib64foo’. It also tried to remove i586 packages if the x86_64 one was already installed (-Uvh didn’t always remove the i586 package.. and of course never for libs). I used a local mirror of a large part of the x86_64 distro for this (15GB or so). Strangely, RPM didn’t really complain about dependency issues (I only ignored them max 3 times, to solve specific problems). Probably the dependencies don’t check the architecture. I had to use –replacefiles more often. The –replacefiles was always due to the i586 libs having the same files as the x86_64 ones (causing conflicts). This didn’t occur too often, I think Mandriva tries to avoid these messages somehow.
Every so often, I used ‘urpmi’ to have it install a few deps. That (perl) command strangely always worked. Even with the mix of i586 and x86_64 packages (I had some perl stuff as i586, some as x86_64.. it still worked).
To check the progress (how many packages still as i586), I used: rpm -qa –queryformat ‘%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n’. In the output, I was only interested in the i586 packages not starting with lib. The amount of those packages started dropping very fast. In the end I looked at ~60 or so packages manually. Some I just removed if I couldn’t find a x86_64 version.
Of course, some stuff broke. E.g., postfix has a deamon_directory in its config file which was correctly updated to the lib64 one. However, pcre in dynamicmaps.cf still pointed to the i586 lib. There was another similar problem (something in /etc/alternatives still pointed to /usr/lib). In total, I have 10 i586 packages left (some packages I made for myself that should actually be noarch, plus things like wine, java plugin, …). This not counting the libs (I did remove the i586 -devel stuff at one point). For something not supported by the distro (Frederic Crozat commented “best way to shoot yourself in the foot”), I expected much worse.
Another solution for your rpm migration issue would have been to convert to sqlite, as the underlying format is likely arch dependent ( not sure ).
And I think some people were able to upgrade i586 => x86_64 in the past, i have heard report of successful upgrade. But it may have been broken since that time, as I guess that’s not one of the tested upgrade path.
Ah, I wondered why I had to install sqlite. I actually read that thread on the Cooker mailinglist, but didn’t think about it until your comment. 🙂
I’ll see if I can convert the database. IMO i586->x86_64 doesn’t have to be supported, but it should be a possible to have the installer at least try.