Should a pkgsrc Makefile be able to rely on execute permissions on files in the pkgsrc tree? (Taken from a pkgsrc-users@ thread as I'm asking for an explicit policy)
I feel that there should be an explicit policy, to be documented in the guide, of:
- pkgsrc must not rely on execute permissions being present on files, and there should be a recommended mechanism to (which could be "Always chmod after copying from files/
to worksrc if it needs to be executable"). Extending it to "Do not set execute permissions on files checked into pkgsrc" might be nice, but I would not mind if that was not the case.
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 there should be a policy, with a note in the guide (I'm happy to make any update).
Background - I had a copy of the pkgsrc tree which had lost execute permissions, so while many packages built fine, pango failed with a not immediately intuitive error:
[85/159] Generating utils/pango-view.1 with a custom command FAILED: utils/pango-view.1
/usr/pkg/bin/help2man --no-info --section=1 --help-option=--help-all '--name="Pango text viewer"' --output=utils/pango-view.1
--no-discard-stderr
/var/obj/pkg/devel/pango/work/pango-1.50.14/output/utils/pango-view.sh
help2man: can't get `--help-all' info from
/var/obj/pkg/devel/pango/work/pango-1.50.14/output/utils/pango-view.sh
ninja: build stopped: subcommand failed.
This was because
pango copies files/pango-view.sh into WRKSRC, assuming the copy in the pkgsrc tree was executable. The issue could be avoided by adjusting pango's Makefile from
to
${INSTALL_SCRIPT} ${FILESDIR}/pango-view.sh ${WRKSRC}/output/utils
While this is may be a minor issue, 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), and I would really like to avoid pkgsrc potentially gifting
something similar onto someone else in future without any clue on how
to fix, particularly as it can happen to a seemingly random package after successfully building many others from the same tree.
David