Quantcast

fail to destroot port with only makefile

classic Classic list List threaded Threaded
8 messages Options
db
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

fail to destroot port with only makefile

db
I'm trying to port a client that comes with only a makefile, but fail to destroot it, although it sort of does if I sudo manually. I attach the log.

https://github.com/tldr-pages/tldr-cpp-client/blob/master/Makefile


main.log (25K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fail to destroot port with only makefile

Ryan Schmidt-24

On Mar 7, 2017, at 10:15, db wrote:

> I'm trying to port a client that comes with only a makefile, but fail to destroot it, although it sort of does if I sudo manually. I attach the log.
>
> https://github.com/tldr-pages/tldr-cpp-client/blob/master/Makefile
>
> <main.log>

The Makefile does not support DESTDIR. Ideally, fix the Makefile to support DESTDIR and submit that to the developers.

This question is better asked on macports-dev, since it's about developing ports, not using existing ports.
db
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fail to destroot port with only makefile

db
On 7 Mar 2017, at 17:29, Ryan Schmidt <[hidden email]> wrote:
> The Makefile does not support DESTDIR. Ideally, fix the Makefile to support DESTDIR and submit that to the developers.

MacPorts Guide links to http://www.gnu.org/prep/standards/html_node/DESTDIR.html, where it states 'You should not set the value of DESTDIR in your Makefile at all'. Eventually, I used
destroot.args        prefix=${destroot}${prefix}

> This question is better asked on macports-dev, since it's about developing ports, not using existing ports.

Sorry, I thought macports-dev was for MacPorts devs only. It's not very practical, I'd rather get mail from topics I start, reply to or am interested in, instead of being subscribed to 2 lists.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fail to destroot port with only makefile

Ryan Schmidt-24

On Mar 7, 2017, at 12:37, db wrote:

> On 7 Mar 2017, at 17:29, Ryan Schmidt wrote:
>> The Makefile does not support DESTDIR. Ideally, fix the Makefile to support DESTDIR and submit that to the developers.
>
> MacPorts Guide links to http://www.gnu.org/prep/standards/html_node/DESTDIR.html, where it states 'You should not set the value of DESTDIR in your Makefile at all'.

That's correct, the Makefile should not set DESTDIR at all, but it should do the right thing if the user running the Makefile sets it; this Makefile does not and should be fixed.

> Eventually, I used
> destroot.args        prefix=${destroot}${prefix}

That can be an acceptable workaround. Sometimes it has side effects. I don't know if it does with this port.


>> This question is better asked on macports-dev, since it's about developing ports, not using existing ports.
>
> Sorry, I thought macports-dev was for MacPorts devs only. It's not very practical, I'd rather get mail from topics I start, reply to or am interested in, instead of being subscribed to 2 lists.

If you're writing a Portfile, you're a MacPorts dev.


db
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fail to destroot port with only makefile

db
On 7 Mar 2017, at 20:00, Ryan Schmidt <[hidden email]> wrote:
> That can be an acceptable workaround. Sometimes it has side effects. I don't know if it does with this port.

Can you give an example?

Something strange I found is that file copy fails silently, no log whatsoever, pre- and post-destroot.

post-destroot {
    file copy ${worksrcpath}/autocomplete/complete.bash \
        ~/.tldr.complete
}
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fail to destroot port with only makefile

Ryan Schmidt-24

On Mar 7, 2017, at 13:27, db 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.
>
> Can you give an example?

Suppose the program builds a dynamic library. The absolute path of the final installation location, including the prefix, will be recorded in the library's install_name. The build system therefore needs to know the difference between the prefix (/opt/local) and the destroot / destdir (the staging directory where files will be installed, prior to being copied by MacPorts to the real destination).


> Something strange I found is that file copy fails silently, no log whatsoever, pre- and post-destroot.
>
> post-destroot {
>    file copy ${worksrcpath}/autocomplete/complete.bash \
>        ~/.tldr.complete
> }

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.

If you need to install config files and such for the user to modify, you can do so in the activate phase (post-activate block). However, you should not attempt to do anything in the user's home directory. The user installing the port is not necessarily the user, or the only user, using the software.

It's likely that in Tcl "~" does not have the special meaning that it does on the shell.


db
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fail to destroot port with only makefile

db
On 8 Mar 2017, at 01:10, Ryan Schmidt <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fail to destroot port with only makefile

Brandon Allbery
On Wed, Mar 8, 2017 at 8:42 AM, db <[hidden email]> wrote:
On 8 Mar 2017, at 01:10, Ryan Schmidt <[hidden email]> 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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
Loading...