On Mon, 2026-09-14 at 08:18 +0200, Matthias Klose wrote: > > sure, you can let it depend on python3-pkg-resources. but this is > one > out of more than 820 packages being affected by this, with around 780 > packages already fixed. What do you gain by delaying? As you said, > upstream work has been stalled, so it's better to keep that package > in > unstable for now. > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pkg-resources-deprecation;[email protected]
There are many of us that use Sid (or testing) on our daily personal machines (so that we're not having to wait literal years for the latest application updates). I've personally been using Sid on my machine for many years now. Breakage is usually very rare and short lasting. Despite being called "unstable", it's actually very stable. There are thousands of people using deluge. I don't know how many on Sid/testing specifically, but I for one would really appreciate careful measures being taken to mitigate as much as possible the impact on Sid users resulting from what has happened here. Taking a look at the link you provided, it seems that you put a lot of work into notifying maintainers well in advance, which is commendable, and this was nearly two years ago, which I appreciate is a frustratingly long period to wait for action (just as how it was very frustrating to wait all of those years for the big gimp update). Strangely the deluge maintainer marked your report as fixed the very next month after you filed it, having apparently simply removed the dependency on python3-pkg-resource without any changes to application code. I don't understand why, since the application seems to require it to load. Similarly, someone else made a report about it in January of this year, which was closed on the same basis. The reporter criticised the solution, yet failed to re-open the bug report. If only deluge maintainer hadn't taken this action of dropping the python3-pkg-resources dependency, then apt wouldn't allow the python3- setuptools upgrade to occur on systems already having deluge, and thus breakage would not be occurring. There'd only be the issue of inability to add deluge to an up-to-date system. Restoring the python3-pkg-resources dependency now may go some way to address the situation, but there's significant risk of this python3- setuptools getting installed before any such deluge update. Blocking the testing migration of python3-setuptools would leave open a path of recovery for such cases, a path that I personally had to rely upon to repair the breakage on my own system. I got lucky that I noticed the breakage and had the opportunity to do so while that path remains open. I'm concerned others may not notice until it's too late. It would also leave open a means of adding deluge to an up-to-date system. Furthermore it would help prevent the breakage spreading to users who prefer to use testing. How long is reasonable to leave such a block in place is difficult to answer. Alternatively perhaps the older copy of python3-setuptools could be re- uploaded under an alternate name with deluge depending upon that for the time being? Taking a quick look through the list of other packages not yet fixed, most have very low popcon numbers (single or double digits). A few stand out with larger use (mate-menu, mate-tweak, astroid, nbclient, paste, pylint, html5lib). Most only seem to use python3-pkg-resources for tests, so maintainers could perhaps just disable the tests temporarily. A few depend upon python3-setuptools which perhaps should have been changed to python3-pkg-resources. The most notable cause for concern is html5lib which ftbfs and has quite a high popcon number.
