On 22/02/2022 12:57, Bernd Zeimetz wrote:
Hi,
I fail to understand why you are opening this bug at all.
rc bugs are how we track packages in testing that are not living up to the
standards Debian sets and ultimately trigger their removal.
"packages must be buildable within the same release" has been part of the rc
policy for as long as I can remember.
collectd would have been removed from testing automatically anyway, people
are notified about that.
To the best of my knowledge there is no mechanism to automatically remove
packages with broken build-dependencies from testing. I certainly
don't recall collectd being listed for autoremoval at the time I filed the
bug.
The auto-removals system does take account of reverse build-dependencies when
deciding what extra removals to trigger, but unfortunately the same does not
apply to manual removals by the release team.
In particular the following scenario can happen.
Package a build-depends (but does not depend) on package b.
Package b is rc buggy.
The autoremovals system sends out mails notifying maintainers that if the
situation doesn't change, it will remove packages b and a
Package b gets manually removed by the release team.
The package with the rc bug is no longer in testing, so it drops off the
autoremoval system's list of issues.
Package a does not actually get autoremoved despite the earlier mail from the
autoremovals system.
I suspect that may well be what happened here (liboping was manually
removed from testing as it was blocking the perl transition).
It basically adds the extra work of tracking and closing this bug manually.
I understand that and that is why I am selective about when I file such bugs.
If I see indications that the underlying issue is likely to be fixed on
a reasonable timescale, I generally will hold-off filing bugs on the reverse
dependencies.
In this case I saw no such indications. The bug report was over a month
old with no maintainer response, and the package had not seen a maintainer
upload in over a year.
If you want to add such bugs, please link them properly to the bugs that
caused the issue and make sure that it is closed automatically as soon as the
issue is fixed.
If the bts had a system to automatically close bugs when another package
migrates
to testing I would use it but afaict it doesn't.
I am not going to build custom automation for such a small volume of bugs.
It certainly makes sense to link to the underlying bug though, I'll try and
remember
that next time.
I guess I could also set "blocks", but i'm not entirely convinced it's
appropriate,
it's the maintainers call not mine as to whether to fix the issue by fixing the
unmaintained package they build-depend on or by eliminating the build-dependency
on it.
