The need for these dependencies and difference from Debian come from the requests "security" extra that I previously described. It looks like one of our dependencies in Xenial (python(3)-cryptography) already depends on python(3)-pyasn1 so there's not currently a problem, but I think it's worth adding one ourselves to avoid problems in the future in case this changes.
James, to give you a bit more detail, I think we could pretty easily make changes to our upstream code to avoid these issues since there doesn't seem to be a good way to indirectly require some of requests' optional dependencies in the .deb packages. I'm happy to talk to you about this more in the future. If I remember correctly, these dependencies are only actually used in very old versions of Python, but we claimed an unconditional dependency on them for simplicity/consistency. The reason I am recommending adding the python(3)-pyasn1 dependency in spite of this is because we declare a dependency on "requests[security]" in setup.py, setuptools will cause the program to crash in some scenarios if this dependency isn't satisfied. We could alternatively change setup.py here, but this to me seems like a more aggressive and risker change than just explicitly specifying a dependency which already transitively exists.
> * The idna dependency should be removed.
I am not sure if Ubuntu's packaging policy has anything to say about this, but this dependency is not actually needed by python(3)-acme in Xenial. This is a dependency of requests' "security" extras in version of requests in Debian, but not the version of requests in Xenial.
With that said, one of our other dependencies (also python(3)-cryptography) depends on python(3)-idna so it is going to currently get installed regardless, but if this would change in the future, a dependency on the package from python(3)-acme would cause it to be installed unnecessarily.
> * The ndg-httpsclient and pyasn1 dependency should be added back.
I would recommend having the python( 3)-ndg- httpsclient and python(3)-pyasn1 dependency. It looks like the python( 3)-ndg- httpsclient dependency is already there in https:/ /salsa. debian. org/ec0- guest/acme/ blob/8346b60b75 50b26c8ae0d57a1 7558fe7c9f64c69 /debian/ control.
The need for these dependencies and difference from Debian come from the requests "security" extra that I previously described. It looks like one of our dependencies in Xenial (python( 3)-cryptography ) already depends on python(3)-pyasn1 so there's not currently a problem, but I think it's worth adding one ourselves to avoid problems in the future in case this changes.
James, to give you a bit more detail, I think we could pretty easily make changes to our upstream code to avoid these issues since there doesn't seem to be a good way to indirectly require some of requests' optional dependencies in the .deb packages. I'm happy to talk to you about this more in the future. If I remember correctly, these dependencies are only actually used in very old versions of Python, but we claimed an unconditional dependency on them for simplicity/ consistency. The reason I am recommending adding the python(3)-pyasn1 dependency in spite of this is because we declare a dependency on "requests[ security] " in setup.py, setuptools will cause the program to crash in some scenarios if this dependency isn't satisfied. We could alternatively change setup.py here, but this to me seems like a more aggressive and risker change than just explicitly specifying a dependency which already transitively exists.
> * The idna dependency should be removed.
I am not sure if Ubuntu's packaging policy has anything to say about this, but this dependency is not actually needed by python(3)-acme in Xenial. This is a dependency of requests' "security" extras in version of requests in Debian, but not the version of requests in Xenial.
With that said, one of our other dependencies (also python( 3)-cryptography ) depends on python(3)-idna so it is going to currently get installed regardless, but if this would change in the future, a dependency on the package from python(3)-acme would cause it to be installed unnecessarily.