From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 Description of problem: The --prefix and --relocate options do not work AT ALL in rpm 4.0.2-7x. Any attempt to use them results in one of several cryptic error messages and a failed installation. Version-Release number of selected component (if applicable): 4.0.2-7x How reproducible: Always Steps to Reproduce: 1. Obtain or build a relocatable RPM 2. Try to install the RPM using rpm --ivh --prefix=PATH (or --relocate OLDPATH=NEWPATH). For example: rpm -ivh --relocate /usr/local=/opt mypackage.rpm 3. RPM will fail with one of several possible error messages, depending on the paths given, and leave behind temporary and mis-installed files. Actual Results: If the relocation prefix directory given already exists (e.g. --prefix=/usr), you will get a conflict message such as: file usr from install of test-junk-1.0-1 conflicts with file from package filesystem-2.0.7-1. If the path given contains embedded slashes (/), they will be mysteriously removed from the path given in the error message, such as: file /usrlocal from install of test-junk-1.0-1 conflicts with file from package filesystem-2.0.7-1. If you give a path which doesn't exist at all (e.g. --prefix=/xxx), RPM attempts to actually do the install and then errors out in the middle: Preparing... ########################################### [100%] 1:test-junk error: can't unlink xxx-RPMDELETE: Is a directory) error: can't rename xxx to xxx-RPMDELETE: Is a directory error: unpacking of archive failed on file xxx: cpio: unlink failed - Is a directory After which, /xxx has not been installed but /xxx-RPMDELETE is left behind. If the RPM happens to contain exactly one file, and you give a path to a directory which doesn't exist (--prefix=/xxx), then the install appears to sort of work: Preparing... ########################################### [100%] 1:test-junk error: can't unlink xxx-RPMDELETE: Is a directory) ########################################### [100%] but after installation, /xxx is not created as a directory, but rather a plain file whose contents is the single file which was in the RPM. In short, relocatable packages are horribly, terribly, tragically broken. I know of no workaround other than installing to the default location and moving the files afterwards, or making symlinks. This kind of defeats the point. Expected Results: The rpm should have been successfully relocated and installed at the given path. Note that this problem seems to occur even for RPMs built with RPM 3.x, so the problem is probably in the RPM installation process and not in rpm-build. Additional info: I would think this would be a SERIOUS problem that would have been noticed immediately, and have been waiting a while for a fixed version to appear. But apparently people don't use relocatable packages much, or noone cares that they arebroken, My company releases commercial software using relocatable RPMs, including an install script that depends on the relocation functionality, so this is a severe problem for us. This following bug (CLOSED) refers to a related problem: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=32517 If the bug fix mentioned in the CVS branch also fixes the problem reported, PLEASE seriously consider back-patching this fix to 4.0.2 and releasing it on updates.redhat.com.
Yup, fixed since rpm-4.0.3-0.6. Latest is rpm-4.0.3-1.03 at ftp://ftp.rpm.org/pub/rpm/test-4.0.3.
But this isn't an official release. I cannot recommend to our customers they upgrade to an RPM from RawHide without knowing what other ramifications this has. What other changes have been made in 4.0.3? When will it be part of an offical release? Would you please comment on my suggestion that the fix be patched into the current "stable" release? Surely having ALL relocatable rpm's be broken is a serious enough problem to warrant this.