Control: tags -1 -moreinfo On Tue, 8 Apr 2025 at 01:04, Guillem Jover <guil...@debian.org> wrote: > > [ 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.
Yeah that's true, I don't know why it was there, the autopkgtest sources have been imported from the Ubuntu fork and it was already there at the time. > 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. Yes often the results are bypassed for some packages, however the list of passes/failures is recorded, which provides very useful information when trying to track down when a regression was first introduced, and I have found this information valuable in other packages in the past, so I'd rather keep it. I'll switch it from build-essential to the gcc metapackage so that dpkg-dev is not included.
