Hi! On Fri, 2026-05-29 at 08:33:53 +0200, Simon Josefsson wrote: > Otto Kekäläinen <[email protected]> writes: > > I am resurrecting this old discussion from 2024 and 2025: I don't like > > how Go builds currently use `_build/` as the build directory, and as a > > consequence lots of Debian Go packages end up modifying the upstream > > `.gitignore` to exclude `_build/`. > > > > I'd rather have build artifacts in `debian/_build` and exclude this > > directory in `debian/.gitignore`.
As I've mentioned multiple times in the past I agree with the sentiment, but definitely not the current path forward. > > A MR that implements this has been open for 1+ years at > > https://salsa.debian.org/go-team/packages/dh-golang/-/merge_requests/26 > > with some thumbs up and no objections. I have advertised and asked > > people to review open team tooling MRs several times on this list, > > most recently in > > https://lists.debian.org/debian-go/2026/05/msg00041.html > > > > If you don't show up to provide feedback when changes are prepared, > > showing up later to revert commits that someone else spent years > > implementing does no one any service. Please take some time to review > > open MRs and PRs now. When sustained opposition and concerns have been brought up already in the past and nothing has changed, having to repeat them on every new iteration push is draining. I also don't think it's fair to say this change required spending years of implementation time. > I support this, and added a thumbs up. > > In which work-flows would anyone care to put '_build/' into .gitignore? > I never understood what kind of build environment anyone would even > notice or care about telling git to ignore Debian build artifacts. (When you build on the same directory as the git tree.) > Thus, I would have been equally fine with a policy to keep using > --builddir=_build and tell people to NOT put _build in .gitignore. > Modifying upstream .gitignore with Debian-specific stuff is horrible, as > it increases auditing costs. I don't see any other real advantage with > putting the builddir beneath debian/ beyond .gitignore, is there one? > > There would be a lot of churn to modify existing go packages to change > _build/ into debian/_build/. I did not see anything in this MR to tell > us to make that change, and I would be mildly against needless churn > just for the sake of policy compliance. It will merely mean the policy > will be out of sync with reality for a long time. So I hope this change > is not a first step towards encouriging go-wide consistency changes, > even though I also happen to like consistency generally (so I could > change my mind on this if we had better tooling to enforce consistency > across packages). As referenced in the MR itself, my plan is to try to unify the default build paths in both dpkg and debhelper, which would take the form (most likely) of namespaced sub-directories under debian/.build/*/ and debian/_build/*/. (I need to discuss this again with Niels, but in general these kinds of global packaging proposals are draining so one needs enough energy to push for them.) Making dh-golang to have conflicting semantics for such pathname in an implicit way (as a default) and burning a compat level for it, when ideally dh-golang would completely delegate that to whatever debhelper uses which would match dpkg expectations as well, will incur additional churn, from the current path to the already known wrong pathname to the final pathname (in different compat levels) While I think changing dh-make-golang for this was unnecessary (the .gitignore part seemed fair though), that to me is less of a concern, because it implies an explicit setting in debian/rules, which is easy to grep for and switch, affecting only newly created packaging, where any "wrong" pathname will incur the same amount of churn, and does not encode this in a compat level that needs to be support for a very long time. So in summary, I'm ok with dh-make-golang adding this explicitly, I'm also ok if maintainers feel strongly enough about this that they want to change existing golang packages they maintain from an explicit _build to an explicit debian/_build, but I'm not ok with encoding this in dh-golang. Thanks, Guillem
