version 3.0.4 of rpm prevents "purp" from running on i386, sparc, ... when purp is launched with an arg (path to RPMS), it dies with some message stating that it could not load some shared library (module fdOpen). After incriminating erroneously glibc, I could find it has to do with rpm. Here is some dirty hack, until it is fixed : Reinstalling old rpm from 6.1 dist. - rpm -e rpm-build-3.0.4 # because of dependencies - rpm -Uvh --force rpm-3.0.3-*.rpm # from redhat-6.1 - rpm -Uvh --force rpm-python-3.0.4-*.rpm # that was overwriten by prev cmd (don't know if I can reinstall rpm-build - which I don't need) "purp" is the only tool I know that can upgrade a remote station thru a text interface.
RedHat has opted to change the RPM shared library ABI between RPM 3.0.3 and RPM 3.0.4 without bothering to even increment the shared library version number, so that there can be a visible indication or warning of coming failures. Unfortunately, since they changed the API at the same time it's not just a simple matter of recompiling the application. While RedHat is free to do this, I think it's a bit suboptimal (among other things, it breaks RPM's dependancy checking!). It should be possible to act like glibc and provide backwards compatable interfaces (or even symbol versioning, perhaps). Or simply avoid breaking the ABI and API in a minor version change in a minor OS revision.
*** This bug has been marked as a duplicate of 11124 ***
If you reinstalled previous version of rpm (3.0.3), so that purp keeps running, don't forget to reinstall now, current version (i.e. rpm-3.0.4) before running new purp-0.9.5 ;-) (ftp://ftp.lysator.liu.se/pub/unix/purp/purp-0.9.5/purp-0.9.5-1.i386.rpm)