These are not bugs per-se, just things to perform at some point.

Changelog: internal
Warned-by: lgtm

Changelog: internal
Warned-by: lgtm

These variables are handled by autoconf, and there's no need to set them
ourselves.

The Perl version in Debian buster is 5.28.1, which is the release that
will be oldstable once 1.21.x gets uploaded to Debian unstable.

[guillem@debian.org: Hook into build system. ]

Signed-off-by: Guillem Jover <guillem@debian.org>

Signed-off-by: Guillem Jover <guillem@debian.org>

Signed-off-by: Guillem Jover <guillem@debian.org>

Changelog: silent

We should ignore any builtin build dependencies (in particular
build-essential, which is an arch:any package), as we are forcing the
build and host architectures, which will make them not match whatever
is on the system status file if present at all, and cause dependency
unsatisfiability.

Fixes: commit 0e2ae4e7

We need to move the symlink tracking from the general loop, which would
limit the depth of the pathname to the case that handles symlinks in the
pathname.

We should not reset the resulting pathname to be the root directory when
the root directory is empty, as that will happen to always match.

Closes: #983855

Only apply the --force-remove-essential and --force-remove-protected
during package removals, which can only happen due to Conflicts,
otherwise we cannot solve auto-deconfigurations due to Breaks on essential
or protected packages during installations or upgrades.

This is a regression when the Breaks field got introduced, as the same
function that had been used for Conflicts was refactored to be used for
Breaks, but without taking into account the removal case.

Fixes: commit b301c0e7
Reported-by: Julian Andres Klode <jak@debian.org>
Ref: #983014

Otherwise we will overwrite any pre-existing log file.

Fixes: commit 2eb9e888

Otherwise we can exit programs with an arbitrary exit code if we call
other commands during the exit hooks.

This was affecting for example a failing dpkg-source invoked from
dpkg-buildpackage.

Otherwise we cannot see what went wrong.

These require dpkg and gcc to be available, which is not guaranteed on
non-Debian systems, or on systems without a compiler, such as the ones
using the CPAN distribution. Or when we are bootstrapping from scratch.

We should not expect dpkg to be present on the system, which can happen
during bootstrapping, or on non-dpkg based systems. We should not expect
gcc to be present on the system, which can happen with the Dpkg perl
distribution which otherwise does not need a C compiler.

On Solaris CPAN testing systems, zcat(1) is an alias for the traditional
uncompress(1), so it does not work as gunzip(1). Use the latter
explicitly to avoid portability issues, and do not assume it will always
be present, when we will skip the unit test.

There is no guarantee that the PERL environment variable will contain
the perl executable path or name. When running the test suite from the
autotools build system we always set the PERL environment variable,
but on CPAN we were not doing that, and some CPAN testers have PERL
set to its version.

There is no guarantee that the perl used will have «.» in INC, so we
need to add an explicit «./» prefix, which we were already doing for
the autotools case. Unify the handling for autotools and CPAN, which
should fix the latter.

Closes: #983865

Closes: #981882
Signed-off-by: Guillem Jover <guillem@debian.org>

Closes: #981884
Signed-off-by: Guillem Jover <guillem@debian.org>

Closes: #980018
Signed-off-by: Guillem Jover <guillem@debian.org>

Fixes: commit 0c782cc2
Changelog: silent

If the lock file does not exist, then in theory no other process is
supposed to have locked the database, as the lock file uses region
locking where the lock file is never supposed to be removed.

In practice, misguided users might end up removing the lock file in an
attempt to "unlock" the database (with potential catastrophic results)
but that is not a supported operation.

The supported scenario where the lock file is missing, is with a database
that has not yet been fully populated.

Reported-by: David Kalnischkies <donkult@debian.org>

Whether we have file descriptor leaks is also dependent on processes
calling dpkg, so we should not print these as failures, as that is
confusing and we might not be able to solve these.

This removes the need to have sudo installed when not really needed.