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 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. But in general, I think that it's desirable for Debian to reinforce the link between upstream-provided sources and the orig tarball, and that debian/watch is a suitable interface to do that. > > - wine: > > https://orig-check.debian.net/orig-check/result/a2f1e53637b4a36179b6b24a825e7a1d94ebf0c6666fc8c9729d0e060584d8c2 > > In 10.0~repack-12, debian/copyright was modified to exclude some files > > from the repacked orig tarball. But since there wasn't a new upstream > > version, the orig tarball was not updated. > >... > > Problems around exclusions could be avoided by only checking whether > every file in the Debian sources is also present and identical in the > upstream sources. Good idea, thanks. I improved orig-check to check for inclusion of tarballs into each other (as in: the tarball generated by uscan is fully included in the tarball in the archive), resulting in splitting the results into those diagnostics: 700 - tarballs not identical (934 packages in sid) 710 - generated tarball fully included in archive tarball (227) 720 - archive tarball fully included in generated tarball (534) 730 - mixed subset relationships between tarballs (4) (details on https://orig-check.debian.net/orig-check/statistics ) Lucas
