On 29/05/26 12:03 pm, Simon Josefsson wrote: > 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.
I am trying to understand as to what problem having debian/_build is trying to solve, really. I also don't seem to understand as to why would anyone ever want to have `_build` inside of `.gitignore`. Aren't we supposed to not disturb any upstream files? > 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? I somehow don't understand how this is even specific to golang packages. I have seen quite some C library packages which (using cmake mostly) output stuff into obj-<arch__triplet> directory in the root itself; and adding that to `debian/clean` is often the right thing to do. Similar to this, why can't we have go tooling add `_build/` to `debian/clean` instead of changing the builddir? On 31/05/26 11:11 am, Simon Josefsson wrote: > Santiago Vila <[email protected]> writes: > >> On Fri, May 29, 2026 at 10:28:01AM +0800, Otto Kekäläinen wrote: >> >>> 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`. >> >> Beware with debian/.gitignore. Packages having such file are not >> "source-reproducible", i.e. "apt-get source package" followed by >> "dpkg-buildpackage -S" may result in a source package which is >> different than the original one in the archive. > > That would be solved by removing debian/.gitignore from git, right? > > The file is incompatible with tag2upload quilt=unapplied, which is how I > prefer to use tag2upload. I see no strong reason for having a > debian/.gitignore at all these days. I see mild reasons for not having > the file, because it breaks source package reproducibility. I'd like > this to be the default Go team style, and for us to care about > binary/source reproducibility generally. I use t2u when possible too, and happen to think that we should avoid d/.gitignore when possible due to source reproducibility too. I'm neither against the proposal nor in favour of it. Just unsure as to what this is going to solve. Best, Nilesh
