On Sat, Aug 05, 2023 at 05:29:34PM +0100, Simon McVittie wrote: > I think it's somewhat inevitable that code paths that aren't frequently > exercised don't work. If a majority of maintainers are doing all of > their builds with git-buildpackage, or dgit --clean=git, or something > basically equivalent to one of those, then `debian/rules clean` will > never actually be run against a built tree. For teams with a strongly > preferred workflow (like the Perl, Python and GNOME teams consistently > using git-buildpackage), this seems particularly likely.
As a minor data point, I also do not rely on `debian/rules clean` to work for reproducing the original source tree, because too many packages fail it. Let me point out though that moving to git-based packaging is not the property that is relevant here. I expect that most developers use either sbuild or pbuilder for the majority of their builds. Both tools create a .dsc, copy that .dsc into a chroot, unpack, build, and dispose of it. So we effectively have at least three ways of cleaning source packages: a) `debian/rules clean` b) Some VCS (and that's probably just git) c) Copy the source before build and dispose the entire copy That last approach may be annoying for large source packages, but it works reliably for the entire archive. > For me, the main purpose of `debian/rules clean` is being able to do > incremental builds while debugging something - but if I want to do > incremental builds, it's quite likely that I'll also be using > `debuild -b -nc` to make the builds genuinely incremental (and then a fully > clean build from first principles at the end, to verify that whatever issue > I'm debugging is really fixed). I see that the purpose of `debian/rules clean` is evolving and that we should clarify which of the purposes we as a project consider important. Given the state of discussion, I think we should drop the idea of using it to construct a source package after build. > One way to streamline dealing with these generated files would be > to normalize repacking of upstream source releases to exclude them, > and make it easier to have source packages that genuinely only contain > what we consider to be source. At the moment, devref §6.8.8.2 strongly > discourages repacking tarballs to exclude DFSG-but-unnecessary files > (including generated files, as well as source/build files only needed on > Windows or macOS or whatever[1]), and Lintian strongly encourages adding > a +dfsg or +ds suffix to any repacked tarball, which makes it less > straightforward to track upstream's versioning. Is it time for us to > reconsider those recommendations? With this you touch another purpose of `debian/rules clean`: Removing generated files. Since we currently discourage repackaging and `dpkg-source -b` is vaguely happy about deleted files, a common technique for dealing with generated files is really shipping them in the source tree and then deleting them via `debian/rules clean` while relying on build tools (and our buildds do this) to clean before build. >From my point of view, this is the main purpose of the clean target at this time. Do others see this strategy of dealing with generated files as viable and is it compatible with git-based workflows? Are we ready to call for consensus on dropping the requirement that `debian/rules clean; dpkg-source -b` shall work or is anyone interested in sending lots of patches for this? Helmut
