Fpm: --rpm-use-file-permissions does not set ownership correctly when using a directory source

[jcbollinger]

I am using fpm 1.8.1 to build RPMs from installed software images, i.e. directory sources. Fpm has been really helpful in this endeavor, but I've run into an issue with a large program that installs files with different owners and groups -- some files and directories are root-owned, whereas others owned by a non-root user associated with the software. I want to package this up so that the file ownership and permissions from the installation image are retained.

The --rpm-use-file-permissions option seems intended for exactly this purpose, but it doesn't work as advertized. When I enable that option, I end up with all files in the package owned by _me_, the packager, not by the owners of the files in the specified directory. On the other hand, when I leave that option out or explicitly disable it (--no-rpm-use-file-permissions), I end up with all files being owned by root.

I speculate that when --rpm-use-file-permissions is enabled, fpm is copying file ownership from the staging area, where all the files will be owned by the user running fpm, instead of from the original source directory.

The --rpm-user and --rpm-group options are not helpful here, because the files to be packaged have multiple owners / groups, and should be packaged as such, but those options set the same user / group on all packaged files.

Here's an fpm command I used for testing this on a minimal example directory:

fpm -s dir -t rpm \
  -n test \
  -v 0.1 \
  --iteration 1 \
  -a noarch \
  --description "Test package for FPM" \
  --rpm-summary "Testing..." \
  --rpm-use-file-permissions \
  --directories /opt/pkg-test \
  /opt/pkg-test

The test directory for that is owned by root and contains two files, one owned by root and the other by a user different from both root and me.

[jcbollinger]

I seem to be able to work around the problem by running fpm with privilege, i.e. sudo fpm .... That reduces the urgency of this issue for me, but it is not satisfactory as a final solution.