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.
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). /Simon Otto Kekäläinen <[email protected]> writes: > Hi, > > 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`. > > 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. > > Thanks! >
signature.asc
Description: PGP signature
