If you got en email that a *_stub owned by you has been dropped from the catalog -- it was me, and your stub is no longer necessary, so you can delete it from your build recipe.
We have multiple recipes defining *_stub packages. When you rename a package, you add a stub (OBSOLETED_BY) - it's simple and good when introducing a new *_stub package, but we are now cleaning our catalogs from unused *_stub packages, and I'm thinking that we (maintainers) will re-upload obsolete stubs just because we don't know they can be removed. This in principle can be done in checkpkg. You can download the state of the catalog, simulate adding/replacing the packages, and seeing if the newly added _stub package has any reverse dependencies. If so, we can throw an error. This would add about 30s-40s to the checkpkg running time. This would require additional code written for checkpkg, because the check functions currently have no access to the catalog as a whole. This feature is not a must, but it would be cool to save constant deletes and reuploads of *_stub packages to the catalog. The positive side is that when we have access to the whole catalog, we can also run cycle detection and dangling dependency detection. This is something that Peter Bonivart was suggesting for a long time, but it has only recently became feasible / practical. Should I write it up as a coding project? Maciej
