Comment 28 for bug 1836823

Revision history for this message
Brad Warren (bradmwarren) wrote :

> * 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/8346b60b7550b26c8ae0d57a17558fe7c9f64c69/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.