Andrew Lee <[email protected]> writes: > Hi Thorsten, > > On Tue, Nov 3, 2026 at 5:14 PM Thorsten Alteholz <[email protected]> wrote: >> On 03.11.26 15:43, Andrew Lee wrote: >> > I think we should have a general guideline or preference for packaging >> > the main repo of a Go project as a whole, rather than splitting out >> > individual submodules, unless there is a strong reason to do so. >> >> I am afraid this is not something that the go-team can decide. According >> to Debian policy 4.13 embedded code copies should be avoided. > > Thank you for the clarification. However, my question was not about > embedded or vendored code, but rather about individual submodules > within a Go monorepo. Monorepos with multiple Go modules are very > common in the Go ecosystem.
Upstream monorepos are horrible for Debian packaging, so I agree with you that Debian should have a general preference for not splitting up upstream-monorepo packages by default. However I do think there could be exceptional cases where something else is reasonable: I forgot which package it was, but I recall packaging some huge upstream monorepo where the Go import path for one sub-directory of interest (like 3 files in a ~10.000 files monorepo) was outside of the monorepo namespace. Then I created a package for that sub-directory only, using some appropriate debian source package name. I may also mis-remember this situation. Or it could be an historic situation that was later fixed by splitting off that component. But still, I think there could be situations like this where having a Debian package for a sub-component of a upstream monorepo is the reasonable choice. /Simon
signature.asc
Description: PGP signature
