Re: Is running dpkg-buildpackage manually from the command line forbidden?
Daniel,
while your effort is valiant, I see a little value in it as there’s no real world use case. While your arguments are valid, you are imposing additional work on generally already overloaded maintainers with unclear goal and purpose.
Perhaps your energy and enthusiasm (which I appreciate) could be spent on helping fixing reproducible builds in packages or cross-building. Those are practical and you won’t find any resistance in accepting patches for these two use cases.
Ondrej
--
Ondřej Surý <ondrej@sury.org>
> On 16 Jan 2020, at 18:21, Daniel Schepler <dschepler@gmail.com> wrote:
>
> 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: