#1141540 uscan: template based watch file (version 5) uses weaker compression

Package:
devscripts
Source:
devscripts
Description:
scripts to make the life of a Debian Package maintainer easier
Submitter:
Michael Biebl
Date:
2026-07-07 08:05:01 UTC
Severity:
normal
#1141540#5
Date:
2026-07-05 23:34:30 UTC
From:
To:
Hi,

I've tried to update the following watch file

version=4
opts="searchmode=plain" \
https://api.github.com/repos/storaged-project/udisks/releases \
https://github.com/storaged-project/udisks/releases/download/udisks-(?:\d[\d.]*)/udisks@ANY_VERSION@@ARCHIVE_EXT@

using the new, template based approach in version 5:


When running uscan with the old, v4 based watch file, I get:

...
    $base               = https://api.github.com/repos/storaged-project/udisks/releases
    $filepattern        = https://github.com/storaged-project/udisks/releases/download/udisks-(?:\d[\d.]*)/udisks(?:[-_]?[Vv]?(\d[\-+\.:\~\da-zA-Z]*))(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|tar\.zstd?|zip|tgz|tbz|txz))
    $newfile            = https://github.com/storaged-project/udisks/releases/download/udisks-2.11.1/udisks-2.11.1.tar.bz2
    $mangled_newversion = 2.11.1
    $newversion         = 2.11.1
    $lastversion        = 2.11.1
uscan info: Matching target for downloadurlmangle: https://github.com/storaged-project/udisks/releases/download/udisks-2.11.1/udisks-2.11.1.tar.bz2
uscan info: Upstream URL(+tag) to download is identified as    https://github.com/storaged-project/udisks/releases/download/udisks-2.11.1/udisks-2.11.1.tar.bz2
uscan info: Filename (filenamemangled) for downloaded file: udisks-2.11.1.tar.bz2
uscan info: Newest version of udisks2 on remote site is 2.11.1, local version is 2.11.1
uscan info:  => Package is up to date from:
             => https://github.com/storaged-project/udisks/releases/download/udisks-2.11.1/udisks-2.11.1.tar.bz2


I.e., it prefers the strongest compression it finds. In this case bz2




In contrast, v5 produces:

    $base               = https://api.github.com/repos/storaged-project/udisks/releases
    $filepattern        = https://api.github.com/repos/[^/]+/[^/]+/tarball/(?>[^/]+(?<=(?:\D|alpha|beta|rc))\-)?(?:[-_]?[Vv]?(\d[\-+\.:\~\da-zA-Z]*))(?:(?=")|$)
    $newfile            = https://api.github.com/repos/storaged-project/udisks/tarball/udisks-2.11.1
    $mangled_newversion = 2.11.1
    $newversion         = 2.11.1
    $lastversion        = 2.11.1
uscan info: Matching target for downloadurlmangle: https://api.github.com/repos/storaged-project/udisks/tarball/udisks-2.11.1
uscan info: Upstream URL(+tag) to download is identified as    https://api.github.com/repos/storaged-project/udisks/tarball/udisks-2.11.1
uscan info: Matching target for filenamemangle: https://api.github.com/repos/storaged-project/udisks/tarball/udisks-2.11.1
uscan info: Filename (filenamemangled) for downloaded file: udisks2-2.11.1.tar.gz
uscan info: Newest version of udisks2 on remote site is 2.11.1, local version is 2.11.1
uscan info:  => Package is up to date from:
             => https://api.github.com/repos/storaged-project/udisks/tarball/udisks-2.11.1


So, v5 would download a .gz tarball.

Is this a deliberate decision of v5? If so why?
If not, could it be changed to behave more like @ARCHIVE_EXT@ in v4.


Thanks for considering.

Regards,
Michael
--- /etc/devscripts.conf ---
Empty.
--- ~/.devscripts --- DEBSIGN_KEYID="09B3 AC2E CB16 9C90 4345 CC54 6AE1 DF0D 608F 22DC"
#1141540#10
Date:
2026-07-05 23:37:36 UTC
From:
To:
The updated v5 version of the watch file looks like this:

Version: 5
Template: Github
Release-Only: yes
Owner: storaged-project
Project: udisks

#1141540#15
Date:
2026-07-07 08:02:03 UTC
From:
To:
...
...
...
...
...

With 'Release-Mode: yes' github template uses what AFAIK is the only path
useful for all projects. With it, is github who creates the compressed
tarball (and uses .tar.gz).

Some projects provide explicit tarballs with other compressions (and
naming schemes), but I think there is no uniform way to reach them (I
think I even saw some projects where tarballs are behind nested
dynamically generated json files). This is also a problem with tarball
signatures, where there is no single way to find them.

Regards,