I've been running a manual test bootstrap of Debian (starting with cross-compiled packages amd64 -> i386 up to the point I was able to install debhelper), and posting a few bugs I've found along the way. These are where I found that having extra packages installed during the dpkg-buildpackage run either failed or resulted in broken packages. (Some examples of the type of thing I mean: #948522, #887902.)
However, I've been getting push back on some of these, with maintainers of the opinion that it isn't actually a bug. So, I thought I'd consult here to get more opinions on whether these are true bugs, or whether I'm at fault for trying to run dpkg-buildpackage manually instead of using it through pbuilder or sbuild. My arguments in favor of such things being bugs: 1. I've been using Debian since before pbuilder or sbuild even existed, and I don't remember ever seeing any announcements along the lines of "using pbuilder or sbuild is now mandatory, running dpkg-buildpackage manually is forbidden". (Just announcements that of course, testing package builds using one of those before uploading is strongly encouraged.) 2. The mere existence of the Build-Conflicts field. 3. The general principle that the Build-Depends are meant not to describe every possible way the package *could* be built, but to pin down the exact environment in which the package *should* be built, in order to avoid unnecessary differences in the resulting packages between architectures. 4. The build-essential package set could evolve over time, and in a few cases that could come back to bite maintainers. For a hypothetical example: what if Debian eventually decided to add cmake, ninja, and meson to the build-essential set? Or, what if there were a source package that made a build time check of whether a libpopt.so.2 file exists to be dlopen()ed, but if it's found enabled broken code; and then, eventually, one of the build-essential packages added a dependency on libpopt? Possible arguments I can anticipate against such things being considered bugs: 1. It would be very difficult to impossible to test for every possible combination of packages that satisfy the Build-Depends. (Though I would think a vast majority of such bugs would be detected by a reproducible-builds type setup with one build being the standard minimal chroot, and the other build using a chroot with as many packages as possible installed.) 2. It would be pointless to worry about such things, especially now that all uploads to the archives must be source only. (To which my answer would be: requiring use of pbuilder or sbuild would place a burden on users who previously would have made local patches by a sequence of "apt-get source package; cd package-*/; edit; dpkg-buildpackage -b -uc; sudo apt-get install ../*.deb ) (Somewhat related to this: I've also found a few packages that hang when building from the command line, waiting for input from stdin; whereas in pbuilder or sbuild, with input redirected to /dev/null or similar, the builds succeed. Would these be considered bugs as well? Of course, in some situations it looks like it detects an incontrovertible bug, such as when an "rm" command hangs on the prompt for confirmation on a read-only file, and the /dev/null stdin case would just result in those files being left in place. I've especially been seeing the latter sort of thing related to Perl packages now that recent Perls install lots of files as read only.) -- Daniel Schepler