<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Le ven. 23 nov. 2018 à 11:10, Mario Emmenlauer <<a href="mailto:mario@emmenlauer.de">mario@emmenlauer.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Dear Eric, thanks for the help! Below more:<br>
<br>
On 22.11.18 18:20, Eric Noulard wrote:<br>
> Le jeu. 22 nov. 2018 à 16:16, Mario Emmenlauer <<a href="mailto:mario@emmenlauer.de" target="_blank">mario@emmenlauer.de</a> <mailto:<a href="mailto:mario@emmenlauer.de" target="_blank">mario@emmenlauer.de</a>>> a écri<br>
>     I'm trying to build an RPM with CPack, and everything seems to work,<br>
>     but the resulting package can not be installed. I get Transaction check<br>
>     error:<br>
>       file / from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64<br>
>       file /opt from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64<br>
>       file /usr/bin from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64<br>
>       file /usr/share from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64<br>
>       file /usr from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64<br>
> <br>
>     I've read in the CPackRPM source code about how to add excludes and<br>
>     CPackRPM says that my "Final list of path to OMIT in RPM" would be<br>
>     /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<br>
> <br>
> <br>
> You can read the doc too:<br>
> <a href="https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST" rel="noreferrer" target="_blank">https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST</a><br>
<br>
Haha, done that! I've read everything I could find, including the<br>
docs and the excellent but hard-to-find community wiki at<br>
<a href="https://gitlab.kitware.com/cmake/community/wikis/home" rel="noreferrer" target="_blank">https://gitlab.kitware.com/cmake/community/wikis/home</a></blockquote><div><br></div><div>OK then you are up-to-doc then.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>     Could someone shed some light? I believe that the problem may be<br>
>     my install command: I call install only once for the full tree<br>
>     of files that I'd like to package:<br>
>       install(DIRECTORY "${INSTALL_TMP_ROOT}/" DESTINATION "/" USE_SOURCE_PERMISSIONS)<br>
> <br>
> Yep this is looking for trouble.<br>
> How did you build the "${INSTALL_TMP_ROOT}" in the first place?<br>
> <br>
> Can't you use relative path install DESTINATION ? For all files/target you build?<br>
<br>
I'm not sure if I can use a relative path. I want to build a system package<br>
that installs to /opt/<package>/ with symlinks in /usr/bin/ and desktop<br>
files in /usr/share/applications/. Since files go into different paths below<br>
system root (/opt, /usr, maybe /var) I assume I need to install into root?<br>
Maybe I misunderstand?<br></blockquote><div><br></div><div>Not really. Usually you install in relative bin/ share/ man/ whatever other subdir you need.</div><div>Then you define CPACK_PACKAGING_INSTALL_PREFIX (see <a href="https://cmake.org/cmake/help/v3.13/variable/CPACK_PACKAGING_INSTALL_PREFIX.html">https://cmake.org/cmake/help/v3.13/variable/CPACK_PACKAGING_INSTALL_PREFIX.html</a>)</div><div>to set up your "main" install prefix for your package. Every CPack generator has a default **packaging install prefix** (not to be confused with CMAKE_INSTALL_PREFIX).</div><div>In your case: </div><div>set(CPACK_PACKAGING_INSTALL_PREFIX "/opt") </div><div>which should even be (AFAIR) the default value for RPM and DEB.</div><div><br></div><div>Concerning the symlink in /usr/bin (or other places /usr/share etc...) this usually done using post-install script</div><div><a href="https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_SPEC_MORE_DEFINE">https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_SPEC_MORE_DEFINE</a><br></div><div><br></div><div>the script itself may call standard symlink creation like <a href="https://linux.die.net/man/8/update-alternatives">https://linux.die.net/man/8/update-alternatives</a></div><div><br></div><div>Sometimes you *really* need absolute prefix like when you install in /etc/init...</div><div>then for those (generally system) specific file you install them with absolute destination.</div><div>CPackRPM is able to handle those as "config" file automatically.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>     I have a wild guess that this install somehow includes the<br>
>     directories, and probably it would be better to just call install<br>
>     on the individual files? <br>
> <br>
> CPack RPM tries its best to avoid shipping directories he does not need to ship, but<br>
> RPM requires that any new (non shared) directory should be specified in the spec file,<br>
> so CPackRPM tries to "discover that" automatically and make the package relocatable.<br>
> <br>
> Installing a whole directory to an absolute DESTINATION (even "/" in you case) is probably <br>
> giving tough time to CPackRPM.<br>
<br>
There is something I don't understand: I can see that CPackRPM removes<br>
several things from CPACK_RPM_INSTALL_FILES, but later rpm complains<br>
about several of the removed items nonetheless. For example /usr/bin.<br>
Does that mean the filtering failed, or does the filter work but (somehow)<br>
the directory still ends up being packaged?<br></blockquote><div><br></div><div>Evil usually hides in details.</div><div><br></div><div>Difficult to say without having the actual code and package to look into it.</div><div>Is your project public? If so could you provide us with the source?</div><div><br></div><div>If not tries to setup a stripped down public project that exhibit the same issue.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>     I would prefer not to call install on the<br>
>     individual files because that overrides file permissions for every<br>
>     file, and I carefully prepared my package upfront to have the<br>
>     exact permissions for installation.<br>
> <br>
> <br>
> How did you "carefully prepared my package upfront" ?<br>
> And what do you mean by<br>
> "because that overrides file permissions for every file"<br>
<br>
Currently I bundle my package in a temporary directory for three reasons:<br>
 - Its easier for me to grasp. I.e. I can nicely inspect the package and<br>
   see what will be bundled before the fact.<br></blockquote><div><br></div><div>make/ninja DESTDIR=/tmp/testinstall all</div><div><br></div><div>may be used equally for that.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 - In the temporary copy, I can override RPATH on binaries and libraries<br>
   without changing them in their actual install location.<br></blockquote><div><br></div><div>If you have a "clean" prefix and relative install path for all binaries then you can safely use $ORIGIN </div><div>see: <a href="https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling">https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 - I prefer file(COPY) over install(FILES) because the former can set<br>
   permissions with complex patterns. I appreciate that file(COPY) allows<br>
   me to set executable permissions on *.so and binaries with a single<br>
   invocation (in a loop over many directories).<br></blockquote><div><br></div><div>if you install(TARGET ..) any binaries or .so would have the appropriate permissions precisely because cmake</div><div>knows what they are and does not consider them as "file" which is the case for install(FILES).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> one more question, could you tell us which version of CPack/CMake you are using?<br>
<br>
I'm on the latest cmake 3.13 as of now, but I tested 3.12.4 as well.<br></blockquote><div><br></div><div>Then you have all bleeding edge feature with you.</div><div><br></div><div>I'm not trying to tell you what to do with your install, I'm just trying what CPack expects.</div><div><br></div><div>install(DIRECTORY ...) is a kind of trap-them-all for things that are not installed otherwise, this is usually used for things like</div><div>generated documentation and not for "normally built artefact" like executable, libraries etc...</div><div><br></div><div><br></div><div>-- <br></div></div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Eric<br></div></div></div></div></div></div></div></div></div></div>