[CMake] CPack RPM: file XXX conflicts with file from package filesystem-yyy...

Mario Emmenlauer mario at emmenlauer.de
Fri Nov 23 05:10:19 EST 2018


Dear Eric, thanks for the help! Below more:

On 22.11.18 18:20, Eric Noulard wrote:
> Le jeu. 22 nov. 2018 à 16:16, Mario Emmenlauer <mario at emmenlauer.de <mailto:mario at emmenlauer.de>> a écri
>     I'm trying to build an RPM with CPack, and everything seems to work,
>     but the resulting package can not be installed. I get Transaction check
>     error:
>       file / from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>       file /opt from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>       file /usr/bin from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>       file /usr/share from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>       file /usr from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
> 
>     I've read in the CPackRPM source code about how to add excludes and
>     CPackRPM says that my "Final list of path to OMIT in RPM" would be
>     /etc;/etc/init.d;/usr;/usr/bin;/usr/include;/usr/lib;/usr/libx32;/usr/lib64;/usr/share;/usr/share/aclocal;/usr/share/doc;/opt;/usr/share/applications
> 
> 
> You can read the doc too:
> https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST

Haha, done that! I've read everything I could find, including the
docs and the excellent but hard-to-find community wiki at
https://gitlab.kitware.com/cmake/community/wikis/home


>     I can see that the conflicting directories are removed from
>     CPACK_RPM_INSTALL_FILES. But that does not satisfy rpm :-(
> 
>     Could someone shed some light? I believe that the problem may be
>     my install command: I call install only once for the full tree
>     of files that I'd like to package:
>       install(DIRECTORY "${INSTALL_TMP_ROOT}/" DESTINATION "/" USE_SOURCE_PERMISSIONS)
> 
> 
> Yep this is looking for trouble.
> How did you build the "${INSTALL_TMP_ROOT}" in the first place?
> 
> Can't you use relative path install DESTINATION ? For all files/target you build?

I'm not sure if I can use a relative path. I want to build a system package
that installs to /opt/<package>/ with symlinks in /usr/bin/ and desktop
files in /usr/share/applications/. Since files go into different paths below
system root (/opt, /usr, maybe /var) I assume I need to install into root?
Maybe I misunderstand?


>     I have a wild guess that this install somehow includes the
>     directories, and probably it would be better to just call install
>     on the individual files? 
> 
> 
> CPack RPM tries its best to avoid shipping directories he does not need to ship, but
> RPM requires that any new (non shared) directory should be specified in the spec file,
> so CPackRPM tries to "discover that" automatically and make the package relocatable.
> 
> Installing a whole directory to an absolute DESTINATION (even "/" in you case) is probably 
> giving tough time to CPackRPM.

There is something I don't understand: I can see that CPackRPM removes
several things from CPACK_RPM_INSTALL_FILES, but later rpm complains
about several of the removed items nonetheless. For example /usr/bin.
Does that mean the filtering failed, or does the filter work but (somehow)
the directory still ends up being packaged?


>     I would prefer not to call install on the
>     individual files because that overrides file permissions for every
>     file, and I carefully prepared my package upfront to have the
>     exact permissions for installation.
> 
> 
> How did you "carefully prepared my package upfront" ?
> And what do you mean by
> "because that overrides file permissions for every file"

Currently I bundle my package in a temporary directory for three reasons:
 - Its easier for me to grasp. I.e. I can nicely inspect the package and
   see what will be bundled before the fact.
 - In the temporary copy, I can override RPATH on binaries and libraries
   without changing them in their actual install location.
 - I prefer file(COPY) over install(FILES) because the former can set
   permissions with complex patterns. I appreciate that file(COPY) allows
   me to set executable permissions on *.so and binaries with a single
   invocation (in a loop over many directories).


> one more question, could you tell us which version of CPack/CMake you are using?

I'm on the latest cmake 3.13 as of now, but I tested 3.12.4 as well.

All the best,

    Mario Emmenlauer


More information about the CMake mailing list