Hi!
If the upstream source includes some bad debian packaging, it's likely
there'll be a watch file somewhere, usually bogus and/or stale.
For this reason, source format 3.0 deletes /debian/ from inside the
tarball -- and if the upstream packaging lives in a non-standard places,
that's harmless as no tool has bogus ideas like searching elsewhere.
Other than uscan, that is.

If there's a bad watch file, let's say source/debian/watch, uscan will
randomly (based on filesystem order?) prefer that over debian/watch.

Source format 3.0 (quilt) doesn't allow deleting files sanely: it ignores
deletions, assuming that the clean target will delete them before build.
This works for anything that calls debian/rules targets, but not for uscan.
Thus, I'd need to repack the .orig tarball just to workaround this.

This is similar to #895982 (uscan looking for debian/changelog in VCS) dirs.

What's even the purpose of search for watch and changelog in places other
than debian/ ?

I find the recursive search feature useful for when I have a large
collection of unpacked source packages in $HOME/src/debian, then I can
"cd ~/src/debian; uscan --report" to check for updates to any of those
source packages.

On Thu, Apr 11, 2019 at 10:40:54AM -0700, Daniel Schepler wrote:
> I find the recursive search feature useful for when I have a large
> collection of unpacked source packages in $HOME/src/debian, then I can
> "cd ~/src/debian; uscan --report" to check for updates to any of those
> source packages.
>
> As for an example I've run into:
> https://ftp.gnu.org/gnu/ncurses/ncurses-6.1.tar.gz contains several
> invalid debian/watch files which trigger error messages in the
> multiple-package uscan run until I manually delete them.

Hmm, I'm not sure which side you're arguing for then. The former sounds
as if you prefer recursive search, while the latter says why it's bad.

My issue with it is that:
* there's no easy way to get rid of a bogus watch file (would need to
repack the upstream tarball)
* our official tools (such as the QA tracker) can't cope with known-bad
output

Even the use case you mention would work better with a shell one-liner
such as:
for x in */debian/watch;do uscan --report "${x%/debian/watch}";done
which won't fall into the bad watch files.