Re: pango fails to build on netbsd-9?

[Greg Troxel <gdt%lexort.com@localhost>]

David Brownlee <abs%absd.org@localhost> writes:

> It was a copy of pkgsrc which had not preserved execute permissions

That explains it.  It's always good to understand what went wrong vs
assuming.

>> How about ${CHMOD} +x with a note that it's working  around a vcs or fs
>> bug?
>
> This is a relatively insidious edge case as I had a full set of
> webmail and database packages all up and running before I hit this
> error, so did not think it was anything other than a package specific
> issue

Copying files into WRKDIR and then  expecting them to be +x is unusual.
The root cause here is that pango upstream is buggy in that it does not
control the load environment during the build.  That should be filed and
fixed upstream and then we can remove this.

> I'm OK for pkgsrc to have a requirement that it "must be run on a copy
> of pkgsrc which has preserved execute permissions", with a note in the
> guide. (though I expect a new user hitting the issue would probably
> end up walking away without finding that as the error is non obvious).

Agreed it is non-obvious.   But generally sources in VCSes expect x bits
to be preserved.  This isn't really a special pkgsrc thing.

> I'd definitely be happy with a requirement that pkgsrc did not assume
> such, though there probably should be an approved method (maybe a
> ${COPY_SCRIPT} as an alias to ${INSTALL_SCRIPT}) to do what is needed.

I see this as a very unusual case, and not necessarily worth a
mechanism.  That's  why I lean to chmod and having

# Make the script executable, in case the x bit from the repository was
# lost.

As for naming, COPY doesn't really lead someone who doesn't understand
to jump to the right conclusion.  It's more like
INSTALL_INTO_WRKDIR_SCRIPT, and there is also cross vs not wrapped up
here.  I think we're better off with a point fix, at least until we know
this is a larger issue.