app-crypt/heimdal (see Bug #185899 for new versions) may be best installed in a separate directory (possibly to solve Bug #168509). To locate that directory, dependent packages should use krb5-config in their configuration. Since the script is provided by both app-crypt/mit-krb5 and app-crypt/heimdal, it may be a good idea to use it as a general means of configuration anyway, no matter what kerberos implementation and installation prefix are chosen. gnome-extra/evolution-data-server requires slight modification to use krb5-config -- and to install with heimdal in a separate directory. Reproducible: Always Steps to Reproduce:
Created attachment 125907 [details, diff] gnome-extra/evolution-data-server-1.10.2 ebuild patch to use krb5-config
Nah; it uses pkgconfig.
(In reply to comment #2) > Nah; it uses pkgconfig. > Please, explain. As far as I know, gnome-extra/evolution-data-server may use pkg-config to _report_ information about itself. Unpatched, it does not use (that is consult) krb5-config to _get_ information about the kerberos installation. Definitely, when I install heimdal-1.0 into /usr/heimdal, the unpatched gnome-extra/evolution-data-server-1.10.2 ebuild fails. The patched one installs smoothly.
Oh, I've forgotten to reopen the bug. Please, leave it open, no matter if you accept my proposal or not, to keep track of the connections of app-crypt/heimdal to other packages. I'm not sure of correct bug dependency usage, so I do not mark Bug #185899 as one this one depends on or blocks.
(In reply to comment #3) > As far as I know, gnome-extra/evolution-data-server may use pkg-config to > _report_ information about itself. Unpatched, it does not use (that is consult) > krb5-config to _get_ information about the kerberos installation. No, it uses pkgconfig to *compile* itself. It shouldn't consult krb5-config, it should use a .pc file provided by heimdal. If heimdal doesn't provide pkgconfig file, then it should grow one. All these *-config scripts are deprecated and stupid.
(In reply to comment #5) > No, it uses pkgconfig to *compile* itself. It shouldn't consult krb5-config, it > should use a .pc file provided by heimdal. If heimdal doesn't provide pkgconfig > file, then it should grow one. All these *-config scripts are deprecated and > stupid. Well, tell that upstream to the heimdal (as well as mit-krb5) developers. Perhaps generating the .pc file by the heimdal ebuild won't be too difficult, I might look at it next time I play with the ebuild (and then suggest similar modification to the app-crypt/mit-krb5 ebuild?), but the evolution-data-server ebuild does this for kerberos: G2CONF="... $(use_with kerberos krb5 /usr) ..." I guess, even if I have .pc file for heimdal, I'll need to patch this ebuild, won't I?
Created attachment 126052 [details] app-crypt/heimdal-1.0.1_rc1 ebuild creating .pc files An ebuild modified from Bryan Jacobs' heimdal-1.0.ebuild (see Bug #185899). Creates krb5.pc, gssapi.pc, kadm-client.pc, kadm-server.pc, and kafs.pc for pkg-config -- but I'm not absolutely sure they are correct.
Created attachment 126054 [details] force_inclusion_by_path.patch for heimdal-1.0.1_rc1.ebuild Bryan Jacobs' patch to put into the files directory of the app-crypt/heimdal ebuilds of the 1.0 series (see Bug #185899).
Created attachment 126056 [details] heimdal-1.0.1_rc1-gentoo-patches-0.1.tar.bz2 Bryan Jacobs' patchset for app-crypt/heimdal (1.0 version, seems to work for 1.0.1_rc1 as well) to put into the portage distfiles directory (see Bug #185899).
Created attachment 126057 [details] script to create the .pc files of app-crypt/heimdal The part of the experimental app-crypt/heimdal-1.0.1_rc1 ebuild responsible for the .pc files creation.
Now I have something as .pc files for heimdal (one for each library reported by krb5-config). Unfortunately just changing the line in the gnome-extra/evolution-data-server ebuild from G2CONF="... $(use_with kerberos krb5 /usr) ..." to G2CONF="... $(use_with kerberos krb5) ..." results in the configuration script looking for the kerberos libraries in ``yes'' directory prefix. Would I have to hack the ebuild basically the same way as for krb5-config usage, or is there some more systematic way, something justifying the .pc file creation, modifying both app-crypt/heimdal and app-crypt/mit-krb5 ebuilds and possibly harassing upstream?
while this would make sense for us to look into it, maybe it would be more efficient to directly work with upstream. What do you think ?
This is hardly a Gnome issue. What Heimdal does is up to its developers. Further more, I'd say this is even less a Gentoo issue. Such modifications should definitely go through Heimdal upstream. @Kerberos Team, feel free to close this bug if you don't want/need the patches. Thanks
(In reply to comment #13) > This is hardly a Gnome issue... > Further more, I'd say this is even less a Gentoo issue. Sorry for messing things up by trying to be cooperative. The hardcoded path is definitely a Gentoo issue. Luckily, as long as heimdal installs simply into /usr, just as mit-krb5 does, and there are no attempts to install more then one kerberos implemantation side by side, it does not bite me. Thus ``Works for me'' and be through with this issue. The stubborn stance ``I wont use krb5-config, because pkgconfig is much better,'' is Gentoo developers issue. A brain bug. Pride, may be. What about ``I won't call configure, because cmake is much better'' or ``I won't compiled this C++ code, because Python/Java/C#/Lisp/CAML/fill-your-favourite-computer-language-here is much better''? Heimdal uses pkg-config, mit-krb5 does not. Hence Heimdal installs heimdal-gssapi.pc file, but nothing for universal kerberos configuration, like krb5.pc, because nothing like that exist. Complain upstream, especially at MIT. krb5-config is universal, I think, definitely common to mit-krb5 and heimdal. The configure script of Evolution dataserver is quite dumb when looking for kerberos. That is a Gnome bug. I might complain upstream eventually, if I really mind. It knows three implementations (MIT, Heimdal and Sun), tests for them, has its own notion of the libraries to link in those three cases, and never lets neither krb5-config nor the user to know better. It asks user for the directories those libraries are installed in, and relies on the answer, no attempt to autodetect here. As long as all the kerberos implementation provided within Gentoo are installed into the same place, and the place does not change, simply hardcoding the path into the configure options works well. If anybody anytime for any reason ends up with kerberos libraries installed, but not exactly at that one particular place, the hardcoded path will backfire. While krb5-config would continue working fine, if only those responsible for the ebuild bothered to use it. If big boys did not eat small rice, only small children could survive in China. But big boys don't use anything besides pkg-config. So it goes.
