On Wed, Mar 8, 2017 at 8:42 AM, db <iams...@gmail.com> wrote:
> On 8 Mar 2017, at 01:10, Ryan Schmidt <ryandes...@macports.org> wrote:
> >> On 7 Mar 2017, at 20:00, Ryan Schmidt wrote:
> >>> That can be an acceptable workaround. Sometimes it has side effects. I
> don't know if it does with this port.
> >
> > In the destroot phase, you should not be attempting to modify anything
> outside of the ${destroot} directory. Only items in the destroot will be
> properly recorded by MacPorts as belonging to that port. I'm not certain,
> but hopefully MacPorts would prevent you from placing files outside of that
> directory.
>
> Yeah, I don't know why I was trying to do that in the first place. Despite
> this, strangely nothing was logged. I submitted the port with ticket #53753
> if you want to take a look at it. I stuck to destroot.args (checked other
> portfiles, some use this, some patch makefile, not univocally), copied
> autocompletion files to {prefix}/share/{subport} (checked porthier) and
> added notes to copy them to a source-able location.
Note that the only way it can prevent writes outside of destroot in the
normal case is simple permissions, and I think even those get hobbled out
of necessity. Trace mode can prevent them, at significant performance cost
(and even higher overhead on Sierra). Debian-style fakeroot (which is more
or less what trace mode gives you here) is not cheap on OS X.
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
