Load versioned gssapi libs #9820
Conversation
|
I don't particularly like this approach. The problem here is actually a bug in https://github.com/apcera/gssapi/ They have a function in https://github.com/apcera/gssapi/blob/master/lib.go#L305 that isn't properly figuring out what the correct suffix should be. I think it would be better for us to work with that upstream to fix the However, given that this is fairly time-sensitive, I guess we could hack around it for now. Inline comments forthcoming. |
| // MIT | ||
| "libgssapi_krb5.so.2.2", | ||
| "libgssapi_krb5.so.2", | ||
| "libgssapi_krb5.so", |
There was a problem hiding this comment.
Are we relying on any feature that's not available from libgssapi_krb5.so.2.0? If not, we should probably not explicitly try to load libgssapi_krb5.so.2.2.
Similarly, we should never try to load the unversioned shared object, because if it jumps to .so.3 at some point, that means that backwards-compatibility has been broken and we shouldn't assume that it works.
There was a problem hiding this comment.
tightened to the current major versions we work with
|
[test] |
|
I agree the upstream component should probably take a list of acceptable lib files, I'll happily defer to it once a default lookup like this moves there |
|
Evaluated for origin test up to 94786fc |
|
continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/6239/) |
|
[merge] |
|
@enj fyi, this was probably why you thought fedora didn't install gssapi by default. on a clean fedora image, edit: maybe you were missing |
|
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/6239/) (Image: devenv-rhel7_4587) |
|
Evaluated for origin merge up to 94786fc |
|
I believe it was the lack of |
|
LGTM |
load versioned shared gssapi libs, rather than the unversioned development lib