Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #86418 > unrolled thread

Bug#1100113: iproute2: Please drop dpkg and build-essential from autopkgtest Depends

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1100113: iproute2: Please drop dpkg and build-essential from autopkgtest Depends Guillem Jover <guillem@debian.org> - 2025-03-11 14:10 +0100
    Bug#1100113: iproute2: Please drop dpkg and build-essential from autopkgtest Depends Luca Boccassi <bluca@debian.org> - 2025-03-11 14:50 +0100
      Bug#1100113: iproute2: Please drop dpkg and build-essential from autopkgtest Depends Guillem Jover <guillem@debian.org> - 2025-04-08 02:10 +0200
        Bug#1100113: iproute2: Please drop dpkg and build-essential from autopkgtest Depends Luca Boccassi <bluca@debian.org> - 2025-04-08 12:20 +0200
    Processed: Re: iproute2: Please drop dpkg and build-essential  from autopkgtest Depends "Debian Bug Tracking System" <owner@bugs.debian.org> - 2025-03-11 14:50 +0100
    Processed: Re: Bug#1100113: iproute2: Please drop dpkg and  build-essential from autopkgtest Depends "Debian Bug Tracking System" <owner@bugs.debian.org> - 2025-04-08 12:20 +0200
    Bug#1100113: marked as done (iproute2: Please drop dpkg and  build-essential from autopkgtest Depends) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2025-04-12 14:00 +0200

#86418 — Bug#1100113: iproute2: Please drop dpkg and build-essential from autopkgtest Depends

Source: iproute2
Source-Version: 6.13.0-1
Severity: wishlist

Hi!

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.

Thanks,
Guillem

[toc] | [next] | [standalone]

#86419

Control: tags -1 moreinfo

On Tue, 11 Mar 2025 14:04:40 +0100 Guillem Jover <guillem@debian.org>
wrote:
> Source: iproute2
> Source-Version: 6.13.0-1
> Severity: wishlist
> 
> Hi!
> 
> 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.

Hi,

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.

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?

[toc] | [prev] | [next] | [standalone]

#86775

[ 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

[toc] | [prev] | [next] | [standalone]

#86783

Control: tags -1 -moreinfo

On Tue, 8 Apr 2025 at 01:04, Guillem Jover <guillem@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.

[toc] | [prev] | [next] | [standalone]

#86420 — Processed: Re: iproute2: Please drop dpkg and build-essential from autopkgtest Depends

Processing control commands:

> tags -1 moreinfo
Bug #1100113 [src:iproute2] iproute2: Please drop dpkg and build-essential from autopkgtest Depends
Added tag(s) moreinfo.

-- 
1100113: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100113
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#86782 — Processed: Re: Bug#1100113: iproute2: Please drop dpkg and build-essential from autopkgtest Depends

Processing control commands:

> tags -1 -moreinfo
Bug #1100113 [src:iproute2] iproute2: Please drop dpkg and build-essential from autopkgtest Depends
Removed tag(s) moreinfo.

-- 
1100113: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100113
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#86843 — Bug#1100113: marked as done (iproute2: Please drop dpkg and build-essential from autopkgtest Depends)

[Multipart message — attachments visible in raw view] — view raw

Your message dated Sat, 12 Apr 2025 11:49:06 +0000
with message-id <E1u3ZMA-00A9R4-CK@fasolo.debian.org>
and subject line Bug#1100113: fixed in iproute2 6.14.0-3
has caused the Debian Bug report #1100113,
regarding iproute2: Please drop dpkg and build-essential from autopkgtest Depends
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1100113: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100113
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web