RFE: provide manylinux binary wheel package about python-gssapi

[simo5]

If you are lucky, random crashes, if not undebuggable behaviors.

[jborean93]

Unfortunately this is not really possible for Linux. See #200 for a more detailed explanation as to why we don't do it for Linux. The reason why we do this for Windows and macOS is because:

• Windows doesn't need to pass the auditwheel requires so can link to a dll that is not provided in the wheel, it requires you to already have the gssapi dll present
• macOS is built against the OS provided GSSAPI library GSS.Framework so we don't have concerns about loading multiple copies of the gssapi library

[ktdreyer]

Thank you for explaining this. The link to #200 helps me understand the history and the bulleted points explain how the Linux situation is different than Windows or macOS. I didn't know that Windows wheels don't have to pass auditwheel.

When Python links to multiple libgssapi_krb5.so libraries (via python-ldap, as explained in #200), what are the problems you would expect to see?

[jborean93]

As for your CI problem you have have multiple stages where you build the artifact or your own wheel using one container and share the binaries with the final one. That allows you to avoid having the development headers and build tools present in the final image but still have the compiled module code.

[ktdreyer]

Sure, I think we'll look into that approach for CI.

We also hit this problem regularly on developer workstations. It's difficult for newer developers to get started with Python scripts or apps that use gssapi-enabled web services.