Re: pango fails to build on netbsd-9?

[David Brownlee <abs%absd.org@localhost>]

On Mon, 4 Sept 2023 at 15:59, Greg Troxel <gdt%lexort.com@localhost> wrote:
>
> David Brownlee <abs%absd.org@localhost> writes:
>
> >> 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.

I have to confess that feel rather strongly that there should be an
explicit decision of:
- pkgsrc must not rely on execute permissions being present on files,
and there should be a recommended mechanism to enforce this where
needed (which could be "Always run a chmod after copying from files/
to worksrc if it needs to be executable")
or
- pkgsrc can always rely on execute permissions being present on
files, and any exception is a user configuration error

My preference is for the former, but it should be one or the other,
with a note in the guide (I'm happy to make any update).

A "find . -type f -perm -100 | wc -l" reports 439 entries for my
normal pkgsrc tree. I have no idea how many of them would cause a
package to fail if they did not have execute permissions (maybe a
dozen, less?) Just adding a quick chmod or similar to this one package
and nothing else feels like the wrong choice.

My apologies if I'm coming across as obstinate or impolite in this,
but I ended up in a bunch of delay and frustration in the middle of
trying to update a box (albeit entirely due to something different I
had done), but I really want to avoid pkgsrc potentially gifting
something similar onto someone else in future without any clue on how
to fix it

Thanks

David