rpm -e kernel-devel: scalability matters.
I'm running Fedora Core on my laptop. One of the habits of that distribution is to install the kernel du jour as part of the usual upgrade process, and to let old ones stick around -- including the kernel-devel packages which tend to have a lot of files with precisely the same names.
After a year or two, trying to remove some old kernel-devel packages will lead to a nasty surprise: rpm needs 1G of memory. My laptop doesn't have that.
Turns out that rpm doesn't deal particularly well with lots of files in lots of packages that have the same or almost the same name. For that reason, there's a list of directories where rpm gets sloppy about checking for duplicates; /usr/src is among them. Unfortunately, this sloppiness leads to loss of files during upgrades. Therefore, some bright engineer decided to deactivate the sloppiness when packages are removed. The result: 1GB of virtal memory is needed to clean up the kernel-devel packages.
There doesn't seem to be a clean work-around -- except possibly in the latest "forked" rpm. My way out of this mess was to download the sources for rpm, disable patch #12 ("exclude") in the spec file, rebuild, and then run rpm using the newly-built instances of librpm and librpmdb. I got rid of the kernel-devel packages quickly, and continue to use the "usual" instance of rpm for everyday purposes.
Thanks for the folks on #rpm for their help!
Still, this entire story points to several instances of rather poor engineering in rpm: The duplicate handling was implemented without any regard for memory consumption or efficiency; the workaround breaks upgrades; and the workaround to the workaround breaks removal of packages again.
Sometimes, I'd wish I was using a Debian-based system.
