On Wed, Feb 11, 2026 at 01:26:48PM +0100, Lucas Nussbaum wrote: > On 06/02/26 at 13:32 +0200, Adrian Bunk wrote: > > On Fri, Feb 06, 2026 at 09:40:51AM +0100, Lucas Nussbaum wrote: > > >... > > > The common denominator used by orig-check is the use of debian/watch. > > >... > > > One case that is difficult to deal with is workflow changes (even minor) > > > outside of new upstream versions. For example, among the current > > > orig-check regressions, there's: > > > - vite: > > > https://orig-check.debian.net/orig-check/result/4506d8769158822444ef829488c2e3107a3844a5d3cad85ef062214d9808ba07 > > > In 1.4-6, the maintainer updated debian/watch to use the tag-based > > > tarball > > > generated by gitlab, while it previously used the manually-generated > > > "release asset" tarball. Since that was done outside of a new upstream > > > release, the tarball used for 1.4-6 does not match the method > > > described in 1.4-6's debian/watch, but rather the method described in > > > 1.4-1's debian/watch. > > > > Such "regressions" are not rare, given the number of packages in unstable. > > > > Paul gave an example of an upstream where no releases were expected with > > debian/watch following git commits - but then there was a one-off tarball > > release that is now in unstable. > > > > It is also very common that debian/watch follows only stable releases, > > and it wouldn't be uncommon if a maintainer anyhow decides to upload > > an RC version to unstable. > > > > A maintainer could also use debian/watch on tarballs only for being > > notified about new releases, with the sources in Debian being created > > in a different way like from a git tree with submodules in a workflow > > without tarballs. > > > > debian/watch is simply meant for a different purpose. > > I don't think that's true. Of course the historical/original purpose of > debian/watch is the detection of new upstream releases, but it has also > been used to generate orig tarballs for a long time. This was first used > only to download new upstream versions, but even its use to download a > specific version is quite common if you look at > https://codesearch.debian.net/search?q=uscan.*--download-%28current-%29%3Fversion&literal=0
"downloading the next version" and "how the current version was downloaded" are identical most of the time, but not always. When you start with wanting to block testing migration, then every obscure corner case suddenly becomes relevant. > Maybe we need an opt-out mechanism for packages to signal that they only > use debian/watch to detect new upstream versions, and that the > generation of orig tarballs is done using a different mechanism. >... What exactly are the use case(s) you have in mind? Some upstreams provide only a tarball for the latest version, so everything you are doing might work fine for testing migration but it would never be possible to verify it later for a version of that package in stable. Upstream locations disappearing is not rare. Upstream might later provide a tarball with the same name but different contents - every obscure or stupid issue imaginable has already happened to some package at some point in time. AFAIR there was some talk from reproducible folks about comparing whether different distributions have the same sources, I could see possible use cases in that area. > Lucas cu Adrian
