Note Adam's comments here. He has a script to help, but also notes that sometimes it is more complicated than just deleting an apparently-missing package. (Sometimes, for example, there should be a replacement.)

I don't think that research should be a rel-eng task, but flagging the problems should be at least, and keeping the file up to date once the correct action is determined.

One thing that might be useful here is if we could somehow automate a run of the check script as part of the package retirement process, and at least generate an issue or an email to somebody or something if any subpackage of a package that's getting retired is listed in comps. That might let us deal with things one case at a time rather than "in a giant blob every few years whenever someone remembers this is a problem".

The other thing we could do which would get these fixed much faster is to make 'missing package' a fatal error not a warning, but to do that we need to clean up all the existing cases first, including all the existing cases where a package should be only listed for certain arches. We never went through and cleaned up all of those after adding the arch code to libcomps.

We discussed this at the weekly releng meeting. This seems to be a good candidate for a new toddler, that will listen to the retirement message run mentioned script and create an issue in the releng tracker.

But first we need to run the clean up again just before enabling the toddler.