> On 01/13/2015 01:55 AM, Domen Vrankar wrote: >> This patch is somewhat related to >> http://public.kitware.com/pipermail/cmake/2014-December/059460.html >> (bug report: http://www.cmake.org/Bug/view.php?id=3602) as it defines >> user and group that should be used for RPM content but on a per RPM >> scale since it is not possible to define it in install command.
The provided patch is only somewhat related because it sets default permissions, user and group on a global scale and can be overwritten per file by install command. Currently all files are by default installed through rpm as root:root (provided patch would at least add global override option for this). > If it were possible to define it in the install() command, that would > be useful for local installs. We would also need the information to > be communicated to the packaging step. If such functionality existed, > would it eliminate the need for a CPack/RPM-specific solution? The functionality described above is a workaround for cases when CPack/RPM doesn't support some file manipulation that RPM spec files support so the functionality would stay in place for the time being but for setting user and group it would no longer be needed. Currently you have to write something like this: install(...) # command used to install file - this should be the only requirement set(CPACK_RPM_USER_FILELIST "%attr(-,usrname,groupname) /opt/some_file") # set something like this for each file individually (making CMakeLists.txt less readable, CPack/RPM generator specific and more error prone) > Should the staged install location for packaging not bother setting uid/gid > because they will be handled by the packaging tool instead? > We need to be able to package on a host machine that does not have the users > or groups of the target machine (perhaps because a pre-install script > in the package creates the users/groups). I'm not certain about other CPack generators but for RPM user and group don't need to exist as rpm packaging tool only sets user and group without actually changing them - they are only actually set on files during rpm installation. RPM spec file requires user and group name and not uid/gid exactly because on install environment the ids will probably differ from packaging environment. That is why uid and gid in install command don't help much - if CPack/RPM would use uid and gid from install command it would be limited to users and groups listed in systems /etc/passwd file. I could write an initial patch for bug report 3602 that would add user and group setting to install command and add that functionality to CPack/RPM and later we could extend the use for install and other CPack generators to use it as well (I also wrote some ideas for a patch here http://www.cmake.org/pipermail/cmake/2015-January/059518.html). >> My question is if such functionality would be useful for other CPack >> packagers as well? > > I would think so. The permissions are a property of the project and > target environment, not of the packaging tools. Each CPack generator > should treat permissions according to the capabilities of its tools > and target environment. In this case I will add the defaults to be set to CPACK_ variables and later the variables can be used by other CPack generators. Regards, Domen -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
