Le mar. 27 nov. 2018 à 14:56, Mario Emmenlauer <ma...@emmenlauer.de> a écrit :
> > Dear Eric, > > just to let you know, your suggestion of using a post-install-script > for all system-wide links and files was indeed the solution to a working > RPM package. Now my files are completely encapsulated in /opt/PKGNAME/ > and install works fine. > Thank you very much for the *positive* feedback, we don't always get those :-) This is nice to me and probably useful to others knowing it finally works. Cheers, Eric Cheers and Thanks, > > Mario > > > > On 23.11.18 15:37, Mario Emmenlauer wrote: > > > > Dear Eric, > > > > thanks a lot for this help! I think I have the pointers to move forward! > > One more detail below: > > > > On 23.11.18 11:36, Eric Noulard wrote: > >> Le ven. 23 nov. 2018 à 11:10, Mario Emmenlauer <ma...@emmenlauer.de > <mailto:ma...@emmenlauer.de>> a écrit : > >> 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 < > ma...@emmenlauer.de <mailto:ma...@emmenlauer.de> <mailto: > ma...@emmenlauer.de > >> <mailto:ma...@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 > >> > >> > >> OK then you are up-to-doc then. > >> > >> > 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? > >> > >> > >> Not really. Usually you install in relative bin/ share/ man/ whatever > other subdir you need. > >> Then you define CPACK_PACKAGING_INSTALL_PREFIX (see > https://cmake.org/cmake/help/v3.13/variable/CPACK_PACKAGING_INSTALL_PREFIX.html > ) > >> 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). > >> In your case: > >> set(CPACK_PACKAGING_INSTALL_PREFIX "/opt") > >> which should even be (AFAIR) the default value for RPM and DEB. > >> > >> Concerning the symlink in /usr/bin (or other places /usr/share etc...) > this usually done using post-install script > >> > https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_SPEC_MORE_DEFINE > >> > >> the script itself may call standard symlink creation like > https://linux.die.net/man/8/update-alternatives > > > > Aha, now I see the recommended approach! Makes perfect sense! So I will > > continue to bundle up everything, but try to avoid files outside my > > man package directory (for me /opt/${PROJECT_NAME}). Then I will make > > the system integration (to /usr/bin, /usr/share, etc) via symlinks > > and update-alternatives in post-install scripts. This makes perfect > > sense, I'm sorry I did not think of it myself! > > > > All the best, > > > > Mario > > > > > > > >> Sometimes you *really* need absolute prefix like when you install in > /etc/init... > >> then for those (generally system) specific file you install them with > absolute destination. > >> CPackRPM is able to handle those as "config" file automatically. > >> > >> > 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? > >> > >> > >> Evil usually hides in details. > >> > >> Difficult to say without having the actual code and package to look > into it. > >> Is your project public? If so could you provide us with the source? > >> > >> If not tries to setup a stripped down public project that exhibit the > same issue. > >> > >> > >> > 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. > >> > >> > >> make/ninja DESTDIR=/tmp/testinstall all > >> > >> may be used equally for that. > >> > >> > >> - In the temporary copy, I can override RPATH on binaries and > libraries > >> without changing them in their actual install location. > >> > >> > >> If you have a "clean" prefix and relative install path for all binaries > then you can safely use $ORIGIN > >> see: > https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling > >> > >> > >> > >> - 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). > >> > >> > >> if you install(TARGET ..) any binaries or .so would have the > appropriate permissions precisely because cmake > >> knows what they are and does not consider them as "file" which is the > case for install(FILES). > >> > >> > >> > 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. > >> > >> > >> Then you have all bleeding edge feature with you. > >> > >> I'm not trying to tell you what to do with your install, I'm just > trying what CPack expects. > >> > >> install(DIRECTORY ...) is a kind of trap-them-all for things that are > not installed otherwise, this is usually used for things like > >> generated documentation and not for "normally built artefact" like > executable, libraries etc... > >> > >> > >> -- > >> Eric > > > > > > Viele Gruesse, > > Mario Emmenlauer > > > -- > BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 > Balanstr. 43 mailto: memmenlauer * biodataanalysis.de > D-81669 München http://www.biodataanalysis.de/ > -- Eric
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake