Hi Guillem, On 4 June 2026 9:56:45 pm IST, Guillem Jover <[email protected]> wrote: >Hi! > >On Tue, 2026-06-02 at 01:21:44 +0530, Nilesh Patra wrote: >> On 01/06/26 4:49 pm, Santiago Vila wrote: >> > On Sun, May 31, 2026 at 06:22:04PM +0530, Nilesh Patra wrote: >> > >> >> Similar to this, why can't we have go tooling add `_build/` to >> >> `debian/clean` instead >> >> of changing the builddir? >> > >> > Or just go tooling remove _build without having to add it to debian/clean. >> > >> > After all, python tooling (dh-python) also removes several common >> > build directories in python packages (example recently added: .pdm-build), >> > so we could follow a similar spirit here. >> >> Right. It removes `.pybuild/` too - for as long as I can remember - many >> years or >> such. I agree that it'd be good for go tooling to just cleanup `_build/`. > >The dh-golang buildsystem (when used) already cleans whatever has been >specified as --builddirectory on the «debian/rules clean» target. The >same with debhelper removing any of the files that it (or dpkg) has >autogenerated. > >This is not the problem at hand though.
Thanks for pointing this out. I did forget about it and the earlier suggestion of moving builddir to `d/clean` is actually wrong or at least un-necessary. Apologies for that. > The problem is that if you do >the equivalent of something like: > > $ debcheckout -a golang-foo > $ cd golang-foo > $ dpkg-buildpackage --build=binary > $ git status > >That shows lots of untracked files, which can easily end up being >committed into git by say «git add -A», and are in general distracting. I think that this is again not specific to go team, and would happen with almost (all?) packages in the archive as one would always get these artifacts whenever a package uses debhelper. The onus is generally on the maintainer to not commit build artifacts, so as such I feel this is not a major issue and we could drop `d/.gitignore` by default in dh-make-golang. That said, I don't have the numbers/statistics (and I don't know if there even exists one) of how frequently maintainers run into committing artifacts. So it is hard to come up with a decision objectively. Best, Nilesh
