Created attachment 151882 [details] svn diff move site-packages to install www/haiwen.... directory.
Created attachment 152222 [details] svn diff
Created attachment 152223 [details] portlint result
Created attachment 152224 [details] testport result
Jingfeng - thanks for all the updates on all these related ports. I have not forgotten them (indeed, the tickets have been claimed by me and are in my "to-do" box), but I'm being pulled in several different ways plus my development machine is currently switched to DragonFly to import gcc 5.0 into base. Thus I've neither had time nor opportunity to do the tickets. Hopefully soon though. I'm more than 50% done with the gcc import.
(In reply to John Marino from comment #4) First of all, thank you for your encouragement. I fully understand your situ. So, you can take your time as long as it is tracked. I have provided a private copy of diffs to Chris (who is working for a lab in Vietnam for Ebola virus research). Chris has done a quite complete deployment for seafile. So, I feel some kind of comforts for current status because there could be no big surprise in the wild.
I think the pkg-plist is wrong. You have @dir in several lines. @dir is only used for empty directories (these aren't empty, right?) and directories with non-standard ownership/permissions. Plus the variable substitution between the files and directories don't match. Can you explain specifically why are you are using @dir here? Is it from an attempt to make stage-qa errors go away?
I'm guessing this was related to the @owner, @group keywords but surely it's not necessary to explicitly list the directories in this case? Don't they follow the permissions of the files inside?
(In reply to John Marino from comment #7) Yes, the @dir lines are only for permission of owner and group. Without the @dir, the directories's permission keep with root (0), while the files are in www/www (80).
Is there a problem if only the file permissions are changed? In other words, if the directories belong to root, does the port malfunction?
(In reply to John Marino from comment #9) I have not tested in that way. however, it could have potential problem is the code test open dir. I originally tried to avoid to use @dir. I do not know the other way to make them consistent. Then I remember that I once installed owncloud and they are putting the www/www for all entries. I checked pkg-plist of owncloud, they are doing the same. I thought the way might be acceptable.
I am skeptical because I've never seen another port do this. As long as the directory has permissions that anyone can write to, I don't think it's necessary. The exception would be if another user needs to create a file, but this should not be happening except in directories like /usr/local/etc, /var, and so on. I would propose to remove all the @dir in all these ports unless there's a specifically identified need for them.
(In reply to John Marino from comment #11) I understand your comments. So far, I only know there is one case which needs write operation for ${LOCALBASE}/www/haiwen/seafile-server/seahub/media/avatar. The files in this directory will be move to another user data location, and this is directory will be used to link that user data directory. I don't except the "Other" have any permission on the web packages. Web packages RW permission typically are given to the owner and group. From my point of view, if the directory permission is not as same as the files, it brings the testing more difficult. There are so many directories, I can not verify all the components which do not hit any issue because of permission issue (because there is no deployment in such way as reference point). For test coverage, if the front end have any problem, it is not very straight to trace the issue to pin down which directory need to have special permission. It is an extra task for me to creating directories list. If the task could be avoided and at the same it does not create any trouble, it would be great. However, if this permission issue creates holes here and there, then the patch could be endless. In such case, I will leave the owner and group to be "root". Let end users to deal with the final user name and group name. If they can run "pkg install" in su, or sudo, they typically should be able to run "chown -R". Could you let me know which way we should pursue? Thank you.
Actually only the files and directory that needs write access needs to be owner by the www user/group all others files/directories should be owned by root/wheel For example I do not see a reason to have %%WWWDIR%%/seafile-server/seafile/%%PYTHON_SITELIBDIR%%/pysearpc/*.py* owned by the WWW user as it will only be read. Given the package do provide the .pyc and .pyo they won't get regenerated at runtime so nothing requires write access here. It is a good thing to cherrypick within the plist the owners as it is also sane for security, WWW will only be allowed to write where it is supposed to.
(In reply to Baptiste Daroussin from comment #13) I will limit the directory to make a test. I wish that there could be only one directory need to be handled separately. BTW, if the directory /x/y/z, the z need to be www/www. As I understand, x and y directory should be keep as it is.
(In reply to Jingfeng Yan from comment #14) ... @owner %%SEAFILE_USERNAME%% @group %%SEAFILE_GROUPNAME%% @mode 664 %%WWWDIR%%/seafile-server/runtime/seahub.conf %%WWWDIR%%/seafile-server/seahub/media/avatars/default-non-register.jpg %%WWWDIR%%/seafile-server/seahub/media/avatars/default.png %%WWWDIR%%/seafile-server/seahub/media/avatars/groups/default.png %%WWWDIR%%/seafile-server/seahub/seahub/settings.py @owner @group @mode @exec install -d -o %%SEAFILE_USERNAME%% -g %%SEAFILE_GROUPNAME%% -m 775 %%SEAFILE_SERVER%%/runtime @exec install -d -o %%SEAFILE_USERNAME%% -g %%SEAFILE_GROUPNAME%% -m 775 %%SEAHUBDIR%%/media @exec install -d -o %%SEAFILE_USERNAME%% -g %%SEAFILE_GROUPNAME%% -m 775 %%SEAHUBDIR%%/media/avatars @exec install -d -o %%SEAFILE_USERNAME%% -g %%SEAFILE_GROUPNAME%% -m 775 %%SEAHUBDIR%%/media/avatars/groups @exec install -d -o %%SEAFILE_USERNAME%% -g %%SEAFILE_GROUPNAME%% -m 775 %%SEAFILE_SERVER%%/runtime @exec install -d -o %%SEAFILE_USERNAME%% -g %%SEAFILE_GROUPNAME%% -m 775 %%SEAHUBDIR%% @exec install -d -o %%SEAFILE_USERNAME%% -g %%SEAFILE_GROUPNAME%% -m 775 %%WWWDIR%% (end of file) All the %%PATH%% are abs path within LOCALBASE. However, this does not change the ownership of the directories. These are min set of directories have to be set with www, otherwise, the service can not run. Any hint?
(In reply to Jingfeng Yan from comment #15) Problem resolved.
Created attachment 152767 [details] svn diff (1) The fix only keep the top level directory in www/www ownership. The requirement is from other ports (net-mgmt/seafile), which writes to this top level directory. (2) This port update also carries on more formal fixes for using the auto tool for BSD system. (3) This port does NOT require further update for version 4.0 series.
Created attachment 152768 [details] testport result The test port result now should include portlint result.
per /usr/ports/CHANGES entry 20140922: I think this line: @exec install -d -o %%SEAFILE_USERNAME%% -g %%SEAFILE_GROUPNAME%% -m 755 %D/%%HAIWENDIR%% should be @dir(%%SEAFILE_USERNAME%%,%%SEAFILE_GROUPNAME%%,755) %%HAIWENDIR%% Can you tell me if that works for you?
(In reply to John Marino from comment #19) Hi John, It does more than what I want. It seems all the sub-dire are in www ownership in this command. What I originally expect is www/haiwen is www/www. The other directory is still root/wheel. I expect this is fine. By the way, there is serious problem in the attached diff. svn diff does not catch the newly added patch file. I should submit the file seperately, or what I can do? Similar question is for deleting file. The "serious" means if anyone take the diff, the port can not be built. Thanks, Jingfeng
Created attachment 152987 [details] unified diff
(In reply to Jingfeng Yan from comment #20) forget to run svn add. It has been corrected.
okay, I'll try this. I have to unmask that rm -rf command in post install. We need to see everything that happens to stage (additional and subtraction)
for some reason, the Makefile.am patch does not apply. Also, you must have used the command line "diff" to create these patches. You should use "make makepatch" so that they are properly formatted, especially the timestamp. I'm short on time right now, can you fix that one line on post-install and regenerated both patches with "make makepatch" and submit a hopefully final patch to the port?
nevermind, I was able to repair the diff and regenerate the patches.
A commit references this bug: Author: marino Date: Mon Feb 16 08:48:21 UTC 2015 New revision: 379073 URL: https://svnweb.freebsd.org/changeset/ports/379073 Log: devel/libsearpc: relocate python files PR: 196921 Submitted by: maintainer (Jingfeng Yan) Changes: head/devel/libsearpc/Makefile head/devel/libsearpc/files/patch-Makefile.am head/devel/libsearpc/files/patch-configure.ac head/devel/libsearpc/pkg-plist
one down...