It is clear that it was a conscious decision to give an error when
downloading a source or binary package to an existing directory (without
-f), but I don't understand what real problem this solves.  On the other
hand, I would expect an error if the output file already exists, and
would expect -f to override this and replace the output file.

The documentation does not specify what happens, with or without -f,
when the destination file exists.  Does -f allow overwriting an existing
.deb file, or just writing the .deb to an existing directory if the .deb
file doesn't exist?

I am writing a script to back out of an upgrade that had unintended
consequences.  The script generates a list of (package, version,
architecture) tuples (a multiarch system with amd64 and i386 packages)
that are not necessarily sorted, and uses debsnap to download the .deb
files.  This script fails because I want both amd64 and i386 versions of
some packages, but because they are requested via separate invocations
of debsnap, the destination dir (but not destination file) already
exists when the second architecture is requested.  The script would
require significant extra logic to sort the tuples and combine different
architectures for the same package into a single debsnap invocation.

I would like to see the behavior changed so that the existence of the
destination directory is irrelevant, and the presence of -f determines
whether to give an error if the output file exists (no -f) or overwrite
a pre-existing output file (-f).

Perhaps if I understood the real use case for the current behavior, I
would be less eager to ask for a change, but it sounds like the current
behavior was designed to guard against unrealistic circumstances, but
fails at doing so.  How do you guarantee that no other process writes to
the destination directory after debsnap creates it?  Under what
circumstances would some other process be trying to write to the
destination directory, and why?

The best you can do is ensure that debsnap does not overwrite an
existing file, and creating a new output directory is neither necessary
nor sufficient to accomplish that.

...Marvin
--- /etc/devscripts.conf ---

--- ~/.devscripts ---
Not present