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