[ Just noticed this while checking the BTS web site, please remember to CC the submitter. ]
On Tue, 2025-03-11 at 13:43:19 +0000, Luca Boccassi wrote: > Control: tags -1 moreinfo > > On Tue, 11 Mar 2025 14:04:40 +0100 Guillem Jover wrote: > > Source: iproute2 > > Source-Version: 6.13.0-1 > > Severity: wishlist > > This package explicitly depends dpkg-dev (which is part of > > build-essential), and build-essential in its autopkgtest Depends, > > where it is also explicitly depending on @builddeps@, which already > > includes the latter (which transitively includes the former). > > > > This is redundant, and has been entangling this package with dpkg's > > testing migration for several Debian releases via its autopkgtests. > > > > Please drop both explicit dpkg and build-essential from the > autopkgtest > > Depends. > > This is intentional, otherwise if a regression was introduced in those > packages that breaks iproute2's autopkgtest, it would not be picked in > unstable, and would start failing iproute2's autopkgtest _after_ they > migrate, instead of _before_, which is the point of debci. I don't see dpkg tools being used at all in the autopkgtest, so I'm not sure how it would affect it. From build-essential the only other versioned dependencies (that are the most common cause for uploads) are the C/C++ toolchains, so I could see how these might be interesting to trigger on version bumps, although these always get a transition handled beforehand. I think the autopkgtest for its reverse deps are currently ignored, otherwise it would not be able to migrate if everything in the archive added this kind of autopkgtest dependencies. > With a quick glance at the results, these tests have always succeeded > since they were enabled in debci. > > Could you please clarify what do you mean by "entangling"? What problem > are you observing, precisely? I went over packages that seem to have gratuitous dependencies, which make dpkg uploads trigger unnecessary autopkgtests which takes time and resources unnecessarily (this is in addition to flaky tests, and issues with autopkgtest nodes). I didn't check whether any such specific package has never failed, because even then it still increases the load. Having explicit dependencies into dpkg-dev from packages that explicitly test or exercise dpkg tools is great, so that regressions on the dpkg side can also be caught early on. This does not seem to be the case here. Thanks, Guillem
