fail to destroot port with only makefile

Brandon Allbery allbery.b at gmail.com
Wed Mar 8 15:56:32 UTC 2017


On Wed, Mar 8, 2017 at 8:42 AM, db <iamsudo at gmail.com> wrote:

> On 8 Mar 2017, at 01:10, Ryan Schmidt <ryandesign at 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
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20170308/ae24fa78/attachment.html>


More information about the macports-users mailing list