Hi I've several times noticed that some reverse build dependency for a package I was working on had some issue. Sometimes I go fix those issues and make an upload of the dependant package first. Only to later realize that the package had no consumer in Debian.
Sometimes upstream was gone and the entire project was deprecated 5-10 years ago. I've reported ftp-master RM bugs for some of these packages. I've made a habit to confirm that a package is actually needed before working on it. After I found zombie packages several time, I started to wonder how many of these we plan to ship in forky... I wrote a small script (see attachment) to make a list. Yes the simplistic logic has both false positives and false negatives, but it is a starting pointer for further pruning. The most obvious false positive is golang-* packages which are new: if a golang-*-dev package without any reverse dependencies was introduced in the last couple of months, it is probably part of preparing for some other new package that will eventually make use of it. A package like that shouldn't be removed. The tool prints 608 packages. I've confirmed several candidates for testing removal by picking a random package name and running ssh mirror.ftp-master.debian.org dak rm -Rn golang-github-templexxx-reedsolomon including for example: https://tracker.debian.org/pkg/golang-github-templexxx-reedsolomon https://tracker.debian.org/pkg/golang-github-mattetti-filebuffer https://tracker.debian.org/pkg/golang-github-ngaut-pools https://tracker.debian.org/pkg/golang-github-pierrec-xxhash https://tracker.debian.org/pkg/golang-gopkg-olivere-elastic.v2 https://tracker.debian.org/pkg/golang-gopkg-freddierice-go-losetup.v1 https://tracker.debian.org/pkg/golang-github-petar-dambovaliev-aho-corasick I think some packages that we made go.mod uploads for are in the list. Packages that we could have removed instead of spending precious team QA time on. My speculative guess is that at least maybe half of the 608 packages are valid candidates for removal. What do you think, is it useful to do mass-pruning of packages like this? What would the best action be -- file a 'serious' bug to trigger testing removal, and possibly offer a place to discuss the package? And after some months after testing removal, ask for ftp-master removal to cover unstable too? Maybe the last step is not essential, but having ancient unused packages in unstable is a QA concern. I think the criteria for mass-bug filing could be: * Be in the output list of my tool * Clean 'dak rm' output (some packages in my list have consumers only in sid, and are thus not immediately relevant) * No non-QA upload in the last three years * Debian Go Team maintained Thoughts? /Simon
#!/bin/sh
set -e
if ! test -f Sources; then
rm -f Sources.xz
wget https://deb.debian.org/debian/dists/testing/main/source/Sources.xz
xz -d Sources.xz
fi
cat Sources | while read line; do
case $line in
"Package:"*)
srcpkg=$(echo $line | sed 's/Package: //')
;;
"Binary: golang"*)
test -z "$srcpkg" && continue
case $line in
# FIXME ignore multi-binpkg sources for now
*,*) continue;;
esac
binpkg=$(echo $line | sed 's/Binary: //')
if ! grep -q "^Build-.*$binpkg" Sources; then
echo $srcpkg
srcpkg=
continue
fi
;;
esac
done
exit 0
signature.asc
Description: PGP signature
