View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0010978 | CMake | CMake | public | 2010-07-11 07:37 | 2016-06-10 14:31 | ||||
Reporter | Angel Tsankov | ||||||||
Assigned To | Kitware Robot | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | moved | ||||||
Platform | OS | OS Version | |||||||
Product Version | CMake-2-8 | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0010978: Why not skip setting permissions on existing directories? | ||||||||
Description | I noticed that when installing a directory cmake tries to set permissions on it even when the directory existed before running cmake. This makes it hard to use package users for package management and I wonder if there is any specific reason why cmake does not skip setting permissions on existing directories. | ||||||||
Additional Information | Happens when cmake 2.8.1 installs kdeartwork and kdebase-workspace (both install <CMAKE_INSTALL_PERFIX>/share/wallpapers/Media_Life/). | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Relationships | |||||||||||
|
Relationships |
Notes | |
(0029819) Chandler Carruth (reporter) 2012-06-25 05:02 |
FYI, this is impacting LLVM developers who are trying out CMake for use by that project. See http://llvm.org/PR4500 [^] which was just hit yet again by one of our developers. |
(0029820) Chandler Carruth (reporter) 2012-06-25 05:03 |
Also, just to add the reason why this bug kind-of matters: The installing user did not have permission to change the permissions of the already existing directory. The user *did* have permission to perform the install though. So this bug actually caused installs that otherwise might succeed to fail. =/ |
(0029829) Brad King (manager) 2012-06-25 14:28 |
Moving to backlog awaiting contributed patch. |
(0034996) Brad King (manager) 2014-01-27 10:24 |
AFAICT CMake does not actually try to set permissions on directories except when using the install(DIRECTORY) command. The install(FILES) and install(TARGETS) modes only set permissions on files they install. They do create directories needed to contain those files, but only with a standard "mkdir" call that sets permissions according to umask. The install(DIRECTORY) command documents how it sets permissions, so it is up to the project CMake code to use the command accordingly. |
(0041728) Kitware Robot (administrator) 2016-06-10 14:28 |
Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2010-07-11 07:37 | Angel Tsankov | New Issue | |
2010-07-13 08:30 | Bill Hoffman | Status | new => assigned |
2010-07-13 08:30 | Bill Hoffman | Assigned To | => Brad King |
2010-07-13 08:48 | Brad King | Relationship added | related to 0009620 |
2010-07-13 08:49 | Brad King | Relationship added | related to 0010126 |
2012-06-25 05:02 | Chandler Carruth | Note Added: 0029819 | |
2012-06-25 05:03 | Chandler Carruth | Note Added: 0029820 | |
2012-06-25 14:28 | Brad King | Note Added: 0029829 | |
2012-06-25 14:28 | Brad King | Status | assigned => backlog |
2012-06-25 14:30 | Brad King | Assigned To | Brad King => |
2014-01-27 10:24 | Brad King | Note Added: 0034996 | |
2016-06-10 14:28 | Kitware Robot | Note Added: 0041728 | |
2016-06-10 14:28 | Kitware Robot | Status | backlog => resolved |
2016-06-10 14:28 | Kitware Robot | Resolution | open => moved |
2016-06-10 14:28 | Kitware Robot | Assigned To | => Kitware Robot |
2016-06-10 14:31 | Kitware Robot | Status | resolved => closed |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |