Open jcbollinger opened 7 years ago
@jcbollinger this behavior seems not good. Here's what I have tested right now, and I'm not reproducing your issue:
Scenario:
FPM:
fpm -s dir -t rpm -n app1 --directories /opt/foo/bar/app1 foo/bar/app1=/opt/foo/bar/app1
fpm -s dir -t rpm -n app2 --directories /opt/foo/bar/app2 foo/bar/app2=/opt/foo/bar/app2
Who owns what?
% rpm -qlp app1-1.0-1.x86_64.rpm
/opt/foo/bar/app1
/opt/foo/bar/app1/app1
% rpm -qlp app2-1.0-1.x86_64.rpm
/opt/foo/bar/app2
/opt/foo/bar/app2/app2
Installing these:
% sudo rpm -i app1-1.0-1.x86_64.rpm app2-1.0-1.x86_64.rpm
% rpm -ql app1
/opt/foo/bar/app1
/opt/foo/bar/app1/app1
% rpm -ql app2
/opt/foo/bar/app2
/opt/foo/bar/app2/app2
Each package only owns what was specified in fpm
command.
This was tested on Fedora 25.
Can you show me an example of what you are doing? I agree, btw, fpm+rpm's handling of directories is really frustrating, and I'd like to improve it if we can.
Apparently, no, I cannot show you an example. I'm not sure what made me think FPM was exhibiting this behavior. Please forgive me for wasting your time with this one.
Wasn't a waste of time - it's good to ask for extra eyes on a problem! The directory behavior of fpm+rpm has always been a bit confusing.
No worries :)
The
--directories
option of FPM 1.8.1 is an unwantedly blunt instrument, at least for building RPM targets from directory sources. When attempting to build multiple RPMs whose installed images share a directory tree, one cannot name the top-level directory as the source, for that would include the whole tree in the package. One wants that directory to be owned by at least one of the packages, however, and the--directories
option seems the only documented means for achieving that, short of intervening to edit a spec file. But the--directories
option also makes the package own all the other directories in the subtree, which one does not want in this scenario.