Widen transitional/dummy package description blacklist

Add 'dummy package' and 'dependency package', the other phrases the
Debian Developer's Reference (6.9.7) documents as convention and that
deborphan --guess-dummy looks for. Deliberately skip bare 'dummy' and
'empty package': both have real false positives in production data
(xserver-xorg-video-dummy, a bridge card 'double dummy solver'
library, python3-roscreate's 'empty package template creator').

Verified against production data: 266 combined matches, still zero
with screenshots.
This commit is contained in:
Christoph Haas 2026-08-24 22:23:04 +02:00
parent 33fc169591
commit 8d26873bae

View file

@ -38,9 +38,17 @@ BLACKLIST_SECTION_PATTERN = [
# List of regular expressions. If the package's short description # List of regular expressions. If the package's short description
# matches any of these then the package will not be imported. # matches any of these then the package will not be imported.
# Transitional/dummy stub packages exist only to ease upgrades to a # Transitional/dummy stub packages exist only to ease upgrades to a
# renamed or split package and never get a useful screenshot. # renamed or split package and never get a useful screenshot. Debian
# has no dedicated metadata field for this - the Developer's Reference
# (6.9.7) documents these exact phrases as the convention package
# maintainers use, and as what deborphan --guess-dummy looks for.
# Deliberately not matching a bare "dummy": too many real packages use
# that word for actual functionality (e.g. xserver-xorg-video-dummy,
# fence-agents-dummy, "double dummy solver" bridge card libraries).
BLACKLIST_DESCRIPTION_PATTERN = [ BLACKLIST_DESCRIPTION_PATTERN = [
/transitional/i, /transitional/i,
/dummy package/i,
/dependency package/i,
] ]
# Whether to delete a blacklisted package from the database # Whether to delete a blacklisted package from the database