Is running dpkg-buildpackage manually from the command line forbidden?
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
Reply to: