The update of python3-setuptools on Sid from version 80.9.0-2 to
84.0.0-2 dropped the dependency on python3-pkg-resources. This may have
been planned for nearly two years (bug #1083766), but it seems deluge
(python-based torrent client) wasn't ready and is now broken. Reverting
python3-setuptools to version 80.9.0-2, which pulls python3-pkg-
resources back in, fixes deluge.

When I say deluge is broken, I mean it simply won't load. Trying to
load on the command line produces the following output:

Traceback (most recent call last):
  File "/usr/bin/deluge", line 5, in <module>
    from deluge.ui.ui_entry import start_ui
  File "/usr/lib/python3/dist-packages/deluge/ui/ui_entry.py", line 20,
in <module>
    import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'

Control: reassign -1 src:deluge

yes, please fix it.

Control: reassign -1 src:deluge

yes, please fix it.

I'm concerned about this simply being reassigned to deluge, rather than
deluge getting marked as affected or a duplicate being made for it. If
deluge were depending on python3-pkg-resources, that might have
prevented me from installing the upgrade and ending up with a broken
application, but unfortunately deluge doesn't currently have such a
dependency. Others could find themselves in the same situation. With
the bug solely on deluge, there's nothing to stop python3-setuptools
from migrating to testing, and if it migrates to testing, then people
won't have an older testing version to downgrade to as a temporary
solution (the traditional solution for such breakage). (There is always
the stable version to downgrade to, but I've never had to downgrade to
a stable package version before and I've no idea if that version would
work).

I've done a little research and found some open MRs on deluge upstream
dating back to last year, so they seem to be very much aware of the
problem and have been working on it, though unfortunately that work
seems to have stalled. There's no knowing how long it may take before
they fix the problem.

I've scanned through the changelog of python3-setuptools and there seem
to be no security bugfixes to put pressure on getting anyone on Sid or
testing upgraded from v80 to v84.

If deluge is made to depend upon python3-pkg-resources, then that might
help mitigate the problem, but is it not sensible to block the python3-
setuptools testing migration for the time being to leave people with
with the option of downgrading to v80.9?

I'm concerned about this simply being reassigned to deluge, rather than
deluge getting marked as affected or a duplicate being made for it. If
deluge were depending on python3-pkg-resources, that might have
prevented me from installing the upgrade and ending up with a broken
application, but unfortunately deluge doesn't currently have such a
dependency. Others could find themselves in the same situation. With
the bug solely on deluge, there's nothing to stop python3-setuptools
from migrating to testing, and if it migrates to testing, then people
won't have an older testing version to downgrade to as a temporary
solution (the traditional solution for such breakage). (There is always
the stable version to downgrade to, but I've never had to downgrade to
a stable package version before and I've no idea if that version would
work).

I've done a little research and found some open MRs on deluge upstream
dating back to last year, so they seem to be very much aware of the
problem and have been working on it, though unfortunately that work
seems to have stalled. There's no knowing how long it may take before
they fix the problem.

I've scanned through the changelog of python3-setuptools and there seem
to be no security bugfixes to put pressure on getting anyone on Sid or
testing upgraded from v80 to v84.

If deluge is made to depend upon python3-pkg-resources, then that might
help mitigate the problem, but is it not sensible to block the python3-
setuptools testing migration for the time being to leave people with
with the option of downgrading to v80.9?

I'm concerned about this simply being reassigned to deluge, rather than
deluge getting marked as affected or a duplicate being made for it. If
deluge were depending on python3-pkg-resources, that might have
prevented me from installing the upgrade and ending up with a broken
application, but unfortunately deluge doesn't currently have such a
dependency. Others could find themselves in the same situation. With
the bug solely on deluge, there's nothing to stop python3-setuptools
from migrating to testing, and if it migrates to testing, then people
won't have an older testing version to downgrade to as a temporary
solution (the traditional solution for such breakage). (There is always
the stable version to downgrade to, but I've never had to downgrade to
a stable package version before and I've no idea if that version would
work).

I've done a little research and found some open MRs on deluge upstream
dating back to last year, so they seem to be very much aware of the
problem and have been working on it, though unfortunately that work
seems to have stalled. There's no knowing how long it may take before
they fix the problem.

I've scanned through the changelog of python3-setuptools and there seem
to be no security bugfixes to put pressure on getting anyone on Sid or
testing upgraded from v80 to v84.

If deluge is made to depend upon python3-pkg-resources, then that might
help mitigate the problem, but is it not sensible to block the python3-
setuptools testing migration for the time being to leave people with
with the option of downgrading to v80.9?

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;users=debian-python@lists.debian.org

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;users=debian-python@lists.debian.org