search

pythongssapi / python-gssapi

A Python interface to RFC 2743/2744 (plus common extensions)
ISC License
103 stars 45 forks source link

Try finding gssapi_ext.h includedir via pkg-config #320

Closed mweinelt closed 1 year ago

mweinelt commented 1 year ago

Gives distros a chance, that put the development headers in a path, that krb5-config does not expose, but for which pkg-config could possibly emit an include directory path.

Related to issues like https://github.com/pythongssapi/python-gssapi/issues/212 and follows up on the train of thought in https://github.com/pythongssapi/python-gssapi/issues/212#issuecomment-941902841.

I don't expect any behavior changes, since we still consider krb5-config the primary source of information, but if it doesn't find anything we try the includedir pkg-config provides.

I have confirmed this fixes the build on nixpkgs after providing pkg-config.

github-actions[bot] commented 1 year ago

This pull request is stale because it has been open for 4 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.

mweinelt commented 1 year ago

this could break scenarios where both MIT krb5 and Heimdal are installed

I'm not sure how to tackle this.

jborean93 commented 1 year ago

I'm not sure how to tackle this.

That's ultimately why the current approach is to use the values from krb5-config in the path. This should give us the prefix for the found krb5-config. It's just that it seems like there was a bug on SLES where it was returning /usr/lib/mit which was how SLES configured the project before moving the files. I think greghudson covers this pretty succinctly with https://github.com/pythongssapi/python-gssapi/issues/212#issuecomment-652452507 in that there are multiple things that might be doing things sub optimally.

Ultimately when testing an install with the SLES 15.1 container image, the krb5 package is now reporting the prefix as /usr like all the other distros. I'm unsure when the fix was introduced but it certainly is there. Based on the current logic I'm not sure it is going to really be possible to have fallback locations. As a workaround for older Suse versions that might still be affected then I think maybe adding an env var override like GSSAPI_EXT_H_PATH that allows a user to specify a custom location to check for the gssapi_ext.h header might be a better approach. Essentially things should work on newer versions but we have a workaround where that might not be the case.

github-actions[bot] commented 1 year ago

This pull request is stale because it has been open for 4 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.