Stuart Henderson wrote:
On 2026/09/28 16:09, David Uhden Collado wrote:
It should also make future github-cli updates easier. When the survey
dependency changes, the patches can be tested directly against the new
upstream version and refreshed or removed if they are no longer needed,
without having to maintain and update a separate fork first.
survey is abandoned upstream so this isn't really a consideration.
(and if it wasn't abandoned we'd probably be able to get this fix
committed upstream anyway..)
+post-extract:
+ ${UNZIP} -oq ${DISTDIR}/go_modules/${SURVEY_MOD}/@v/${SURVEY_V}.zip \
+ -d ${WRKDIR}/survey-extract
+ mv
${WRKDIR}/survey-extract/github.com/AlecAivazis/survey/v2@${SURVEY_V} \
+ ${WRKDIR}/survey
+ rm -rf ${WRKDIR}/survey-extract
+
+post-patch:
+ patch -d ${WRKDIR}/survey -p0 \
+ < ${FILESDIR}/patch-survey_terminal_runereader_posix_go
+ patch -d ${WRKDIR}/survey -p0 \
+ < ${FILESDIR}/patch-survey_go_mod
it would indeed be nice to have a proper way to patch go modules
and, if we had that, moving from the fork to port patches would make
sense. that would be useful for much more than just github-cli.
but this approach with ${FILESDIR} and these custom targets isn't
really a sustainable properly-integrated way to do this.
I agree. In this particular case, if survey is abandoned upstream, then
the argument about making future upstream updates easier does not really
apply.
More generally, though, I think it would be useful to improve the ports
infrastructure for languages with their own package managers, and
perhaps make the different modules behave a bit more consistently.
For example, the Go module can generate its .inc files without mixing
unrelated output into the generated data. With Cargo, the equivalent
workflow is less clean and often requires working through temporary
files rather than writing the generated information directly where it
belongs. Cabal is further behind in this regard, since there is no
equivalent mechanism in the ports infrastructure at all; you currently
need an external tool such as cabal-bundler, and parts of that workflow
can end up using and modifying the user's home directory instead of
keeping everything contained under places such as /usr/obj or
/usr/distfiles.
So I agree that the custom ${FILESDIR} plus post-extract/post-patch
approach is not a good general solution. A properly integrated mechanism
for patching vendored Go modules would be much better, and I think there
is also a broader opportunity to make the Go, Cargo, and Cabal module
workflows more homogeneous where that makes sense.
