On Feb 14, 2018, at 2:46 PM, Ken Cunningham <ken.cunningham.web...@gmail.com> 
> On 2018-02-14, at 5:56 AM, Ryan Schmidt wrote:
>> We will definitely never offer a user-facing feature for building the HEAD 
>> version of a port's code. 
> I completely recognize why you stick with this, I totally get it, but this 
> caution is costing MacPorts both users and mindshare to do so... some people 
> want this, and so will go elsewhere to get it.
> In a recent poll 
> <https://www.slant.co/versus/1588/1674/~macports_vs_homebrew>, homebrew was 
> recommended 375 to 25 over MacPorts.
> Most developers who offer their software for download and building manually 
> recommend homebrew for supporting software. Almost nobody recommends MacPorts.

sure, it's not clear that that's because MacPorts doesn't provide un-repeatable 
HEAD builds.

> Reasons for this are likely to be:
> 1. a one-line copy-paste install script that can be embedded into any webpage.
> 2. symlinks into /usr/local therefore:
>    a) no adjustments needed to path
>    b) no need for sudo
>    c) third-party apps, libraries, and xcode projects can be downloaded and 
> built or run, and the system looks there by default, so need no modification 
> to build or run. 
> 3. you can easily build the +HEAD version of a git project to try out newest 
> changes as a beta tester
> IMHO, the two biggest reasons homebrew is heavily recommended are #1 and #2c. 
> I think it's just good that we all know this.
> Question:
> Is there anything that would stop someone from installing macports into 
> /usr/local ,

yes, the configure script purposely errors out if you try to do this (I ran 
MacPorts this way for a /long/ time - there's no real benefit from doing so).

> should they desire to do so? That would fix up all the issues with sudo, 
> path, and 2c.

MacPorts already works with non-sudo if you want (we could probably make it 
Daniel J. Luke

Reply via email to