Why is ${prefix}/var/macports/home not owned by the macports user?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Why is ${prefix}/var/macports/home not owned by the macports user?

MacPorts - Users mailing list
Hi,

I am currently preparing a port file for the new port MacPass [1]. Installing and building works fine, but I do get some warnings because a tool preparing the build called carthage wants to create a file in ${prefix}/var/macports/home/Library. This fails because the folder is owned by root. Why is that?

I think the home folder of the macports user should be owned by macports, no?

If it is intended that the folder is owned by root, is there another way I can grant (temporary) write permissions to that folder to the macports user?

Thanks,
Janosch


[1] https://github.com/Janosch/macports-ports/blob/new-port-macpass/security/MacPass/Portfile
Reply | Threaded
Open this post in threaded view
|

Re: Why is ${prefix}/var/macports/home not owned by the macports user?

Andrew Udvare

> On 2020-12-31, at 10:49, Janosch Peters via macports-users <[hidden email]> wrote:
>
> [1] https://github.com/Janosch/macports-ports/blob/new-port-macpass/security/MacPass/Portfile

Just some comments on the port:

Line 13 (name) is not necessary because github.setup sets the name (second argument).

Does the build {} step actually download deps with Carthage? (I am fairly certain it does). This should be avoided even if it is difficult. If Carthage is downloading dependencies, then a fully offline installation is impossible with this port (think of users who suddenly have poor network conditions who still have distfiles on their machine and need to reinstall). For Rust and Go ports, we set the Portfile to download everything in the fetch phase and then build a compatible environment. This allows offline installation and avoids potential security issues. I have a Portfile that does a similar thing for an Xcode project with submodules: https://github.com/Tatsh/ports/blob/master/aqua/Fanny/Portfile#L17

You can do that, or you can make a separate port for each dependency (or subports in your port to keep it all in one file). My mas port uses separate ports for dependencies and depends on Commandant, which would normally come via Carthage: https://github.com/Tatsh/ports/blob/master/sysutils/mas/Portfile, Commandant: https://github.com/Tatsh/ports/blob/master/devel/Commandant/Portfile

Probably should add to xcode.destroot.settings:

CODE_SIGN_IDENTITY=- CODE_SIGN_STYLE=Manual ENABLE_HARDENED_RUNTIME=NO

Last one is for future proofing in case the project decides to enable it, which it probably will. With the way xcodebuild runs it's not possible to build with that option because it requires signing.

The fetch.type git should be removed as you should set the submodules to be downloaded in the fetch phase (and remove post-fetch phase). See https://github.com/Tatsh/ports/blob/master/aqua/Fanny/Portfile#L17 for an example. Then in the pre-configure or some other phase (post-extract is probably most appropriate), move the other extracted contents to the appropriate place in the source.

The build {} with 'carthage bootstrap' should no longer be necessary once these changes are made. And your issue with the home directory not being writable would be resolved since you do not need to run the carthage command (and you can remove the dependency too).

Your comment about being able to switch to distfiles once a release is made is not correct if you are referring to submodules. Tarballs from GitHub do not come with submodules but instead just come with empty placeholder directories where the submodules would be.

Carthage is much more for development of an app and not for package managers to invoke.

--
Andrew
Reply | Threaded
Open this post in threaded view
|

Re: Why is ${prefix}/var/macports/home not owned by the macports user?

ryandesign2
Administrator
In reply to this post by MacPorts - Users mailing list


On Dec 31, 2020, at 09:49, Janosch Peters wrote:

> I am currently preparing a port file for the new port MacPass [1]. Installing and building works fine, but I do get some warnings because a tool preparing the build called carthage wants to create a file in ${prefix}/var/macports/home/Library. This fails because the folder is owned by root. Why is that?
>
> I think the home folder of the macports user should be owned by macports, no?
>
> If it is intended that the folder is owned by root, is there another way I can grant (temporary) write permissions to that folder to the macports user?

No, it is intentional that ports cannot write to that home directory. We do not want it to fill up with junk.

When a port is installed, MacPorts creates a new home directory just for that port, within the port's work directory. MacPorts sets the HOME environment variable to the path to that directory. Most tools honor that environment variable. If the tool you are using does not honor that, you could file that as a bug with the authors of that tool.

Reply | Threaded
Open this post in threaded view
|

Re: Why is ${prefix}/var/macports/home not owned by the macports user?

MacPorts - Users mailing list

> Am 31.12.2020 um 19:41 schrieb Ryan Schmidt <[hidden email]>:
>
> On Dec 31, 2020, at 09:49, Janosch Peters wrote:
>
>> I think the home folder of the macports user should be owned by macports, no?
>
> No, it is intentional that ports cannot write to that home directory. We do not want it to fill up with junk.
>
> When a port is installed, MacPorts creates a new home directory just for that port, within the port's work directory. MacPorts sets the HOME environment variable to the path to that directory. Most tools honor that environment variable. If the tool you are using does not honor that, you could file that as a bug with the authors of that tool.

Ok. Thanks for clarifying. I filed a bug for Carthage: https://github.com/Carthage/Carthage/issues/3101
Reply | Threaded
Open this post in threaded view
|

Re: Why is ${prefix}/var/macports/home not owned by the macports user?

MacPorts - Users mailing list
In reply to this post by Andrew Udvare

Just some comments on the port:

Line 13 (name) is not necessary because github.setup sets the name (second argument).

Does the build {} step actually download deps with Carthage? (I am fairly certain it does). This should be avoided even if it is difficult. If Carthage is downloading dependencies, then a fully offline installation is impossible with this port (think of users who suddenly have poor network conditions who still have distfiles on their machine and need to reinstall). For Rust and Go ports, we set the Portfile to download everything in the fetch phase and then build a compatible environment. This allows offline installation and avoids potential security issues. I have a Portfile that does a similar thing for an Xcode project with submodules: https://github.com/Tatsh/ports/blob/master/aqua/Fanny/Portfile#L17

You can do that, or you can make a separate port for each dependency (or subports in your port to keep it all in one file). My mas port uses separate ports for dependencies and depends on Commandant, which would normally come via Carthage: https://github.com/Tatsh/ports/blob/master/sysutils/mas/Portfile, Commandant: https://github.com/Tatsh/ports/blob/master/devel/Commandant/Portfile


The fetch.type git should be removed as you should set the submodules to be downloaded in the fetch phase (and remove post-fetch phase). See https://github.com/Tatsh/ports/blob/master/aqua/Fanny/Portfile#L17 for an example. Then in the pre-configure or some other phase (post-extract is probably most appropriate), move the other extracted contents to the appropriate place in the source.

Thanks for the review. I will try to create separate ports for all dependencies currently fetched by carthage and also implement your other suggestions.

Your comment about the git submodules is a bit surprising to me because I got that part straight from the macports guide: https://guide.macports.org/index.html#reference.portgroup.github.submodule. So is fetching the submodule „manually“ considered the better approach? Should we update the guide?

I will update the PR as soon as I have created port files for all dependencies - that may take a while though.

Janosch

 


Reply | Threaded
Open this post in threaded view
|

Re: Why is ${prefix}/var/macports/home not owned by the macports user?

Andrew Udvare

> On 2021-01-07, at 07:09, [hidden email] wrote:
>
> Your comment about the git submodules is a bit surprising to me because I got that part straight from the macports guide: https://guide.macports.org/index.html#reference.portgroup.github.submodule. So is fetching the submodule „manually“ considered the better approach? Should we update the guide?

I don't think the guide needs an update. It says 'the best distfile candidate (if available) is a distfile from GitHub releases'. If a project doesn't have a proper release system you can do what the guide says here, but there are drawbacks as with anything. Unfortunately most projects on GitHub don't really care about users building from source so there is never just one way to do this.

I would suggest the guide get an update to note the technique of manually merging the source together from a series of distfiles but that's kind of an advanced topic.

It's really just my own personal preference to avoid using `fetch.type git` and similar things. I like being able to perform offline (re)installations (possible to do as long as distfiles are present). I like having distfiles for everything rather than some distfiles and some repositories. Mostly a Gentoo user habit.

--
Andrew Udvare
Reply | Threaded
Open this post in threaded view
|

Re: Why is ${prefix}/var/macports/home not owned by the macports user?

Andrew Udvare
In reply to this post by MacPorts - Users mailing list
Sometimes the release tarball will come with the submodule source https://github.com/macports/macports-ports/pull/9612#issuecomment-756376258 but this probably depends on the project.

On Thu, Jan 7, 2021, 07:09 <[hidden email]> wrote:

Just some comments on the port:

Line 13 (name) is not necessary because github.setup sets the name (second argument).

Does the build {} step actually download deps with Carthage? (I am fairly certain it does). This should be avoided even if it is difficult. If Carthage is downloading dependencies, then a fully offline installation is impossible with this port (think of users who suddenly have poor network conditions who still have distfiles on their machine and need to reinstall). For Rust and Go ports, we set the Portfile to download everything in the fetch phase and then build a compatible environment. This allows offline installation and avoids potential security issues. I have a Portfile that does a similar thing for an Xcode project with submodules: https://github.com/Tatsh/ports/blob/master/aqua/Fanny/Portfile#L17

You can do that, or you can make a separate port for each dependency (or subports in your port to keep it all in one file). My mas port uses separate ports for dependencies and depends on Commandant, which would normally come via Carthage: https://github.com/Tatsh/ports/blob/master/sysutils/mas/Portfile, Commandant: https://github.com/Tatsh/ports/blob/master/devel/Commandant/Portfile


The fetch.type git should be removed as you should set the submodules to be downloaded in the fetch phase (and remove post-fetch phase). See https://github.com/Tatsh/ports/blob/master/aqua/Fanny/Portfile#L17 for an example. Then in the pre-configure or some other phase (post-extract is probably most appropriate), move the other extracted contents to the appropriate place in the source.

Thanks for the review. I will try to create separate ports for all dependencies currently fetched by carthage and also implement your other suggestions.

Your comment about the git submodules is a bit surprising to me because I got that part straight from the macports guide: https://guide.macports.org/index.html#reference.portgroup.github.submodule. So is fetching the submodule „manually“ considered the better approach? Should we update the guide?

I will update the PR as soon as I have created port files for all dependencies - that may take a while though.

Janosch

 


Reply | Threaded
Open this post in threaded view
|

Re: Why is ${prefix}/var/macports/home not owned by the macports user?

ryandesign2
Administrator


On Jan 7, 2021, at 16:26, Andrew Udvare wrote:

> Sometimes the release tarball will come with the submodule source https://github.com/macports/macports-ports/pull/9612#issuecomment-756376258 but this probably depends on the project.

If a release tarball doesn't come with everything needed to build the source (i.e. with submodules included), then it's of no use to anyone. So that would be a bug to report to whoever prepared that tarball.

Reply | Threaded
Open this post in threaded view
|

Re: Why is ${prefix}/var/macports/home not owned by the macports user?

MacPorts - Users mailing list

> Am 08.01.2021 um 15:50 schrieb Ryan Schmidt <[hidden email]>:
>
> On Jan 7, 2021, at 16:26, Andrew Udvare wrote:
>
>> Sometimes the release tarball will come with the submodule source https://github.com/macports/macports-ports/pull/9612#issuecomment-756376258 but this probably depends on the project.
>
> If a release tarball doesn't come with everything needed to build the source (i.e. with submodules included), then it's of no use to anyone. So that would be a bug to report to whoever prepared that tarball.
>

Unfortunately, for GitHub this bug seems to be the default: https://github.community/t/create-release-that-contains-submodule/1329. And they are apparently not really eager to fix that.


Reply | Threaded
Open this post in threaded view
|

Re: Why is ${prefix}/var/macports/home not owned by the macports user?

ryandesign2
Administrator


> On Feb 4, 2021, at 09:11, [hidden email] wrote:
>
>
>> Am 08.01.2021 um 15:50 schrieb Ryan Schmidt:
>>
>> On Jan 7, 2021, at 16:26, Andrew Udvare wrote:
>>
>>> Sometimes the release tarball will come with the submodule source https://github.com/macports/macports-ports/pull/9612#issuecomment-756376258 but this probably depends on the project.
>>
>> If a release tarball doesn't come with everything needed to build the source (i.e. with submodules included), then it's of no use to anyone. So that would be a bug to report to whoever prepared that tarball.
>
> Unfortunately, for GitHub this bug seems to be the default: https://github.community/t/create-release-that-contains-submodule/1329. And they are apparently not really eager to fix that.

*Automatically-generated* GitHub tarballs ("archive" and "tarball" types, in the parlance of the github portgroup) do not contain submodules. For that reason, and others, developers may choose to *manually generate* a tarball that contains submodules and anything else necessary and upload that to the GitHub Release object ("release" type, according to github portgroup). A developer who manually creates and uploads such a tarball but fails to include submodules or other necessary files does nobody any favors. That's what I was saying. I was not referring to automatically-generated tarballs.