#1012764 empty Build-Depends-Indep in debhelper errors

Package:
apt
Source:
apt
Description:
commandline package manager
Submitter:
Mark Esler
Date:
2022-06-13 19:57:04 UTC
Severity:
normal
#1012764#5
Date:
2022-06-13 16:26:13 UTC
From:
To:
In the debian/control file setting Build-Depends-Indep to nothing
or whitespace will cause a build failure.

dh appears unable to parse an empty Build-Depends-Indep list:

E: Problem parsing dependency: Build-Depends-Indep
E: Unable to get build-dependency information for gccgo-6
ERROR: Something went wrong with automatic dependency resolution.

I am using Ubuntu 22.04, kernel 5.15.0-30-generic, with
debhelper 13.6ubuntu1.

Mark

#1012764#10
Date:
2022-06-13 17:05:41 UTC
From:
To:
This is for an older version of dh than stated in the initial bug report.
Occurs in at least 9.20160115ubuntu3.

#1012764#15
Date:
2022-06-13 17:04:03 UTC
From:
To:
Hi Mark,

That is an interesting special-case you found.  Particularly because I
was certain it was not allowed at all and was ready to close the bug.
But then Debian Policy decided to throw this little gem in my direction:

"""
Empty field values are only permitted in source package control files
(debian/control). Such fields are ignored.
"""
(from §5.1)

However, none of those error messages are from debhelper.  A codesearch
finds the second line in apt, so @deity tag you are it.

(For reference, I tried adding an empty Build-Depends-Indep and did a
full dpkg-buildpackage locally without any issues assuming build
dependencies were already installed.  So I am pretty debhelper/13.7.2
and later works correctly in this case)

Thanks,
~Niels

#1012764#24
Date:
2022-06-13 19:47:04 UTC
From:
To:
I assume the later mail mentioning debhelper 9.20160115ubuntu3 – why
would that version be used in a 2022 release – and gccgo-6 – which was
removed from Debian unstable more than 3 years ago – is a better
indication of the release window we are talking about being somewhere
in 2016 or 2017 rather than the claimed 2022.
https://salsa.debian.org/apt-team/apt/-/commit/7ea3c67f96e3bc82f86afe72d6c61308c92de515

That would explain why with a ~2016 release something like that would
fail with apt being involved. As the example package from #875363 existed
in the archive I suppose other tools (like debhelper) were more
accepting even back then through. At least I believed that back then as
I mention this in the commit message…


On a slightly related note:
Earlier last year "Allow superfluous commas in build-dependency lines"
https://salsa.debian.org/apt-team/apt/-/commit/d7e3d28412c5269276d8d7cd72427ab88ee3e3d1

That is all about 'apt build-dep .' through which ist mostly done by
humans. Official build infrastructure uses still mostly temporary
packages to achieve the same thing… and in those these values would
indeed be unsupported as its the task of the tool creating the
dummy package + archive and so on to clean fields then. So, could it be
that you use some (own) tool which doesn't and feeds bad data to apt?

(The provisioning Niels quoted is for debian/control files, not for
DEBIAN/control inside binary packages or stanzas in Packages and Sources
files… those aren't written by hand, so a nice clean machine readable
format is assumed and expected for speed reasons.)


I am closing this bugreport hence as the provided information is at best
misleading and certainly not helping in identifying a culprit. While
e.g. the "E:" lines are certainly from apt, apt isn't really involved
with debhelper and neither prints "ERROR: Something went wrong with
automatic dependency resolution."

Feel free to reopen or report a new bug if you can provide details about
how to reproduce your problem. The more details the better as if this
problem is fixed you will still need a compelling case for having it
backported…


Best regards

David Kalnischkies