On 2026/09/29 13:25, David Uhden Collado wrote:
> 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.
in most cases that is trivial to deal with in scripts that at least some
of us regular porters already use, no big need to change it
(and this is unrelated to patching)
> 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.
yep
> 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
jsing had some ideas and a diff for this but we got mired down in making
the changes to the module work with existing ports.
if anyone wants to pick this up, i suggest copying lang/go/go.port.mk
to lang/go/old/old.port.mk and move existing ports to MODULES=lang/go/old.
i'd really want most existing ports to work with a modified module as-is,
but if some are resistant they can be left using 'old' as a fallback.
working on this will need a SUBDIRLIST file with a wide range of the
existing go.port.mk-users for test builds across the wide range of
users ("select fullpkgpath from ports where modules like '%lang/go%';"
with sqlports), a huge gob of disk space in WRKOBJDIR because go
ports use a ridiculous amount of space to build, and a lot of
patience...
> and I think there is also a
> broader opportunity to make the Go, Cargo, and Cabal module workflows more
> homogeneous where that makes sense.
the implementations of these are already complicated, adding homogeneity
between them (which are already very different parts of the system) is
a big extra burden on developers, the cost/benefit doesn't stack up for me
