Hello,
I’m trying to debug and fix issues with Kerberos based authentication on both Icecat and qutebrowser and got a few questions:
Via strace I found that icecat tries load `libgssapi.so` which doesn’t exist.
Trivially creating the file as a symbolic link to the `libgssapikrb5.so` provided by the `mit-krb5` package and exposing via LDLIBRARYPATH solves the issue and fixes Kerberos based authentication.
- Question 1: Should this be fixed in the mit-krb5 package or in the icecat package?
Question 2: What would be the best way of creating this link in a package?
I’ve played with creating a modified `mit-krb5` (i.e. `my-mit-krb5`) with the following additional build phase:
(modify-phases %standard-phases (add-after ’install ’create-link (lambda _ (let* ((libpath (getenv “out”)) (origin (format #f “~a/lib/libgssapikrb5.so” libpath)) (target (format #f “~a/lib/libgssapi.so” libpath))) (symlink origin target)) #t))
This works, but creates the link with full path target instead of relative like the rest of links created naturally by the original build process:
❯ ls -l /gnu/store/irhvqdpc4zvyj9in514lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapi* lrwxrwxrwx 3 root root 21 Jan 1 1970 /gnu/store/irhvqdpc4zvyj9in514lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapikrb5.so -> libgssapikrb5.so.2.2 lrwxrwxrwx 3 root root 21 Jan 1 1970 /gnu/store/irhvqdpc4zvyj9in514lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapikrb5.so.2 -> libgssapikrb5.so.2.2 -r–r–r– 2 root root 380520 Jan 1 1970 /gnu/store/irhvqdpc4zvyj9in514lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapikrb5.so.2.2 lrwxrwxrwx 7 root root 82 Jan 1 1970 /gnu/store/irhvqdpc4zvyj9in514lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapi.so -> /gnu/store/irhvqdpc4zvyj9in514lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapikrb5.so
Should I try to `chdir` to the path before creating the link, or is there a cleaner way of doing something like this?
qutebrowser Kerberos support comes from `qtwebengine`. The only change needed would be to add `mit-krb5` as input and add the “–webengine-kerberos=yes” qmake option in its `configure` build phase.
My question here is about whether there is any policy requiring formal justification to increase the number of dependencies of a certain package or this would be considered a valid request/patch.
Best regards,
Ignacio