When I previously used equivs-build, the .deb file was generated in the
current working directory, but with version 2.1.0 it preferentially uses
$TMPDIR.  In principle, this is a good change, but it would be helpful
if the man page states where the package ends up.  (I spent about an
hours trying to debug, until I finally thought to look at the source
code...)

Thanks!

Marten

Hi,
like mk-build-deps or, like in bug #1081839, debootsnap and thus also
debrebuild. The effect we see is, that on systems with TMPDIR set, debrebuild
will fail with:

    E: Unable to locate package debootsnap-dummy

If debrebuild is run without TMPDIR set, it will succeed. The current behaviour
makes equivs-build hard (or at least very surprising) to use in scripts where
the program running equivs-build expects a reliable location of the artifacts
as they are produced by equivs-build. Figuring out that the bug you are trying
to reproduce is due to TMPDIR being set or not is very frustrating and cost me
and Holger many hours of our lives.

At the very least, please accept the patch at the bottom of this mail which
documents this behaviour.

Even better, maybe add an option to equivs-build which allows scripts that
use it to set the output directory in a deterministic way.

While I'm here: is equivs still developed/maintained? The version in unstable
is the same as the version in oldstable and this bug is from 2018 and has no
replies. Maybe scripts written today should be using something else?

Thanks!

cheers, josch
--- equivs-2.3.1/equivs-build.pod	2018-11-13 21:44:07.000000000 +0100
+++ equivs-2.3.1+nmu1/equivs-build.pod	2024-09-16 09:46:29.000000000 +0200
@@ -14,6 +14,11 @@
 can be created with equivs. These can be used as "profile" packages
 which just mark other ones for installation.

+The resulting packages are placed in the current working directory (not in the
+parent directory as indicated by B<dpkg-buildpackage> output) or, if the
+I<TMPDIR> environment variable is set, in the filesystem location indicated by
+the I<TMPDIR> environment variable.
+
 Please note that this is a crude hack and if thoughtlessly used,
 it might possibly do damage to your packaging system. And please
 note as well that using it is not the recommended way of dealing