Hi Manuel, First, thank you for maintaining pycares and aiodns in Debian!
Manuel Guerra (2026-01-15): > The problem is not inherently with pycares... see bug #1123948, which > explains that dependent packages need to update to the new API of > version 5, as version 4 is no longer functional. The upstream project > introduced breaking changes to the API. Well, it's of course upstream's prerogative to change their API in ways that are not backwards-compatible, and then to expect consumers of said API to adjust. That's fine. In the case at hand, it turns out that "dependent packages need to update to the new API" are primarily aiodns, which you also maintain. The job of a distribution such as Debian is to smooth this out for the final users, by maintaining a consistent set of packages that work well together. That's why uploading a package that we know will break lots of reverse-dependencies requires coordination and a proper transition plan, e.g. with testing of reverse-dependencies for example via experimental, then bugs filed before the upload to sid against those reverse dependencies, so that once it's finally time to upload to sid, everybody involved has had a chance to get ready. AFAICT this did not happen here, hence the resulting confusion and all impacted parties trying to understand what's going on here, because our basic assumptions are not matched. To me it seems the upload of pycares was premature, because 1 of its reverse-dependencies (aiodns), that itself has a bunch of reverse-dependencies, has no version that's both compatible with pycares 5, and ready for Debian. If the resulting breakage can't be fixed in a timely manner, I humbly suggest considering a revert to pycares 4 (with a "really is" version number since it'll be short-lived hopefully, so no need for an epoch). But perhaps I'm missing part of the puzzle, and the pycares 5 upload was necessary to fix a bigger problem than the one it introduces? Cheers, -- intrigeri
