Package: devscripts
Version: 2.19.4
Followup-For: Bug #905866
Hey folks,
I'm also running into problems with uscan processing debian/watch files
in subdirectories. Looking at the manpage, it *seems* to say it only
scans `debian/watch`, but at the end of the manpage, under ADVANCED
FEATURES, it says:
uscan actually scans not just the current directory but all its
subdirectories looking for debian/watch to process them all. See
"Directory name checking".
Looking at the section "Directory name checking", it says:
Similarly to several other scripts in the devscripts package, uscan
explores the requested directory trees looking for debian/changelog
and debian/watch files. As a safeguard against stray files causing
potential problems, and in order to promote efficiency, it will
examine the name of the parent directory once it finds the
debian/changelog file, and check that the directory name corresponds
to the package name. It will only attempt to download newer versions
of the package and then perform any requested action if the directory
name matches the package name.
and then goes on to detail how this directory name checking works
exactly. AFAICS, this directory name checking should protect against
these stray watch files in most of the cases, but apparently it is not
working.
To reproduce:
$ mkdir -p subdir/debian
$ (cd subdir; dch --create --package test --newversion 1.0.0-1)
$ touch subdir/debian/watch
$ uscan --report
$ uscan --report-status
uscan info: uscan (version 2.19.4) See uscan(1) for help
uscan info: Scan watch files in .
uscan info: Check debian/watch and debian/changelog in ./subdir
uscan info: package="test" version="1.0.0-1" (as seen in
debian/changelog)
uscan info: package="test" version="1.0.0" (no epoch/revision)
uscan info: ./subdir/debian/changelog sets package="test"
version="1.0.0"
uscan info: Process watch file at: debian/watch
package = test
version = 1.0.0
pkg_dir = ./subdir
uscan info: Scan finished
AFAIU, "subdir" should have matched /^test(-+.)?/, which does not seem
to be the case, so this check seems broken in uscan?
However, I'm actually wondering if this recursive scanning by default is
a good feature at all. Two considerations:
- There currently seems to be no way to disable this behaviour at all,
if it turns out to be problematic?
- The most common usecase seems to be scanning for new versions of a
single package, where this recursive scanning is not needed at all.
Would it not make sense to just scan the current directory by
default, and add an option to enable recursive scanning for usecases
that need it?
Gr.
Matthijs
