Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop modifying upstream .gitignore file and put build artifacts in debian/build/ #248

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

ottok
Copy link
Contributor

@ottok ottok commented Feb 19, 2025

See commits for details. This is a re-submission of #230, pending to be merged potentially in the summer of 2025.

…urces

Instead of putting build artifacts in `_build/` at the project root,
where they pollute the upstream sources and lure some people to also
modify the upstream `.gitignore` file, put it in `debian/build/` along
with all other build artifacts that get generated in `debian/`.
The fact that Debian builds produce extra files in the build directory
is a separate concern and should not be managed by .gitignores in upstream
directory. Anyways, the list is not going to be complete on most packages,
and instead of extending the list, a better practice is to have proper
`make clean` rules in the `debian/rules`, or to simply run `git clean -fdx`
between builds. Additionally, everyone should be using `gbp pq` to update
patches instead of legacy Quilt, so no more `.pc` directories should be
generated.
Copy link
Contributor

@NightTsarina NightTsarina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM to removing changes to upstream .gitignore, but maybe we can remove the custom builddirectory too?

Comment on lines +303 to +308
fmt.Fprintf(f, "\tdh $@ --builddirectory=debian/build --buildsystem=golang\n")
// Note: The above `--builddirectory=debian/build` will eventually be obsolete
// in 2028+ then the dh-golang version 1.63+ that has
// https://salsa.debian.org/go-team/packages/dh-golang/-/commit/bc16dff5381b668a71fa99c381baba202c34c789
// is in use everywhere

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering dh-golang 1.63 is already in testing, I think we could remove this completely. After all, these tools are meant to be used from sid..

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The omission of the --builddirectory option is dependent on the debhelper compat level, see the dh-golang(1) man page for the rationale, and debhelper compat 14 is not yet stable.

@guillemj
Copy link
Contributor

LGTM to removing changes to upstream .gitignore, but maybe we can remove the custom builddirectory too?

From the commit reverting the previous change:

While the general idea makes sense and would make things better, this
had some push back on the review and still got merged anyway. It also
conflicts with an old proposal that still is pending to be updated
and re-proposed to try to unify the build paths for all packages at the
dpkg and debhelper layer, via a new dpkg-build-api level. And doing a
migration twice seems wasteful.

Ref: https://lists.debian.org/debian-dpkg/2020/03/msg00003.html

So, I agree with the idea of the change, but probably not in this specific form.

@ottok
Copy link
Contributor Author

ottok commented Feb 23, 2025

In summary, the proposal from 2020 in https://lists.debian.org/debian-dpkg/2020/03/msg00003.html is instead of all these and more:

  - debian/files
  - debian/*substvars
  - debian/<binary-pkgname>/
  - debian/*debhelper.log
  - debian/.debhelper/
  - debian/tmp/

..just have this:

  - debian/.build/

with all artifacts there.

This would certainly help keep the debian/* stuff tidy and help people learning Debian packaging understand clearly what is a build artifact and what is not. However since this hasn't moved since 2020 I am not sure if it makes sense to postpone tidying things up in Go debian/rules while waiting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants