(0004749)
Brad King (manager)
2006-08-25 10:06

I've added a reference to this bug from bug#2691 which is a central bug to collect progress on install features.

(0004750)
Brad King (manager)
2006-08-25 10:09

I agree this feature needs to be addressed, but it may not be straightforward.

Setting permission bits during installation is easy because it always works. Changing the owner and group is not so easy because:

1.) What if the owner or group specified does not exist on the system.
2.) What if setting owner/group is not allowed because the install directory is in a user home directory and the user is not root?

Currently it is possible to do this using the INSTALL(SCRIPT) or INSTALL(CODE) commands. You can add your own call to EXECUTE_PROCESS at install time to run chown and chgrp.

(0009574)
Oswald Buddenhagen (reporter)
2007-10-26 13:37

the conditions in your case 2) are bogus, at least on any modern unix system. anyway ...

in case of failure one would simply error out like when the file cannot be installed in the first place.

as an additional option, one could add "soft fail", i.e. continue
despite failure. however, in this case the chown must be attempted first and any requested setuid/setgid be only chmoded when the chown succeeds.

dealing with case 1) by auto-creating users/groups is a perfect way to get into distribution compatibility hell. :)
but done right, it might be an actual selling point.

(0009589)
Brad King (manager)
2007-10-29 09:30

Case 2 is as follows:

~/ $ touch foo.txt
~/ $ chown other foo.txt
chown: changing ownership of `foo.txt': Operation not permitted

Now that I'm thinking about this again I'll add case 3:

3.) What if installing into a DESTDIR that exists on a mount point and the user names should be translated to uids with $(DESTDIR)/etc/passwd instead of /etc/passwd? How should this be specified?

Still, a solution to this problem would be useful.

(0030500)
Brad King (manager)
2012-08-13 10:36

Sending issues I'm not actively working on to the backlog to await someone with time for them.

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it:

http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer or contributor who has the bandwidth to take it on.

(0037705)
Brad King (manager)
2015-01-15 15:03

Relevant mailing list thread:

Specifying a file owner
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/51354 [^]

(0041316)
Kitware Robot (administrator)
2016-06-10 14:27

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.

Issue History
Date Modified	Username	Field	Change
2007-10-26 13:37	Oswald Buddenhagen	Note Added: 0009574
2007-10-29 09:30	Brad King	Note Added: 0009589
2012-08-13 10:36	Brad King	Status	assigned => backlog
2012-08-13 10:36	Brad King	Note Added: 0030500
2015-01-15 14:51	Brad King	Relationship added	related to 0002691
2015-01-15 14:56	Brad King	Relationship added	related to 0014714
2015-01-15 15:03	Brad King	Note Added: 0037705
2016-06-10 14:27	Kitware Robot	Note Added: 0041316
2016-06-10 14:27	Kitware Robot	Status	backlog => resolved
2016-06-10 14:27	Kitware Robot	Resolution	open => moved
2016-06-10 14:30	Kitware Robot	Status	resolved => closed

Notes
(0004749) Brad King (manager) 2006-08-25 10:06	I've added a reference to this bug from bug#2691 which is a central bug to collect progress on install features.

(0004750) Brad King (manager) 2006-08-25 10:09	I agree this feature needs to be addressed, but it may not be straightforward. Setting permission bits during installation is easy because it always works. Changing the owner and group is not so easy because: 1.) What if the owner or group specified does not exist on the system. 2.) What if setting owner/group is not allowed because the install directory is in a user home directory and the user is not root? Currently it is possible to do this using the INSTALL(SCRIPT) or INSTALL(CODE) commands. You can add your own call to EXECUTE_PROCESS at install time to run chown and chgrp.

(0009574) Oswald Buddenhagen (reporter) 2007-10-26 13:37	the conditions in your case 2) are bogus, at least on any modern unix system. anyway ... in case of failure one would simply error out like when the file cannot be installed in the first place. as an additional option, one could add "soft fail", i.e. continue despite failure. however, in this case the chown must be attempted first and any requested setuid/setgid be only chmoded when the chown succeeds. dealing with case 1) by auto-creating users/groups is a perfect way to get into distribution compatibility hell. :) but done right, it might be an actual selling point.

(0009589) Brad King (manager) 2007-10-29 09:30	Case 2 is as follows: ~/ $ touch foo.txt ~/ $ chown other foo.txt chown: changing ownership of `foo.txt': Operation not permitted Now that I'm thinking about this again I'll add case 3: 3.) What if installing into a DESTDIR that exists on a mount point and the user names should be translated to uids with $(DESTDIR)/etc/passwd instead of /etc/passwd? How should this be specified? Still, a solution to this problem would be useful.

(0030500) Brad King (manager) 2012-08-13 10:36	Sending issues I'm not actively working on to the backlog to await someone with time for them. If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^] It's easy to re-activate a bug here if you can find a CMake developer or contributor who has the bandwidth to take it on.

(0037705) Brad King (manager) 2015-01-15 15:03	Relevant mailing list thread: Specifying a file owner http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/51354 [^]

(0041316) Kitware Robot (administrator) 2016-06-10 14:27	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.