Alternate worksrcpath (Re: ~/.macports)

[Joshua Root]

On 2015-2-13 02:29 , Rainer Müller wrote:
> On 2015-02-11 02:30, Ryan Schmidt wrote:
>>
>> On Feb 10, 2015, at 5:47 AM, Clemens Lang wrote:
>>
>>> On 10 Feb, 2015, at 11:37, René J.V. Bertin wrote:
>>>
>>>> As I said, my ~/.macports on my Mac appears to be unused since november 2013 or
>>>> so. However, the tiny test install I have on my Linux system does contain a lot
>>>> of things that appear to be copies, but also things like "home" the function of
>>>> which is unclear to me.
>>>
>>> ~/.macports is used instead of /opt/local/var/macports when you run MacPorts in
>>> a root installation but without root privileges. As such, MacPorts will put
>>> downloaded tarballs, work directories and build support files there when you,
>>> for example, run
>>>  port build qt4-mac # note the lack of sudo
>>
>> This "feature" was added at some point. I never want this behavior, so I ensured that it never takes place on my system using "chmod 000 ~/.macports/{opt,Users}". Now, if I ever forget to use sudo, I just get a permission denied error, like I used to before this feature was added, thus reminding me that I need to use sudo.
> 
> I don't think the alternate worksrcpath in ~/.macports is still useful.
> I proposed its removal a while ago, but Joshua asked me to keep it:
> https://lists.macosforge.org/pipermail/macports-dev/2012-March/018055.html
> 
> Thanks to the work by Clemens, trace mode should be good enough now to
> cover this use case. We could finally get rid of the confusing alternate
> worksrcpath feature.

My use case was covered by sandboxing. As portsandbox.tcl says, "# TODO:
remove altprefix support". :)

So yeah, it can definitely go.

- Josh