-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 28 Nov 2013 06:46:05 +0100 Stephan Kulow <coolo@suse.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 27.11.2013 23:25, schrieb NeilBrown:
On Wed, 27 Nov 2013 19:20:45 +0100 Stephan Kulow <coolo@suse.de> wrote:
Hi,
It's currently impossible to submit packages from Base:System due to repo-checker blocking submissions as base packages suddenly require krb5.
This is due to a change in libtirpc, that creates a huge cycle. As I'm protecting Factory from having that cycle too, I block such updates. Unfortunately the check hits other packages in the cycle too, so this means: unless this change is reverted, it won't be possible to submit base packages.
Greetings, Stephan
Do really understand much of this, but I'll tell you what I know.
1/ libtirpc doesn't work properly without the recent change. It causes rpc.gssd to crash whenever someone tries to perform a secure NFS mount. 2/ nfs-utils is in Base:System and it already depends on krb5 so I don't understand why this introduces a new dependency.
(just FYI libtirpc is used only by nfs-client, nfs-kernel-server, pam, autofs and rpcbind)
So I don't understand what the problem is, or why there is a problem or what sort of approach might fix it. So I cannot be much help here.
The problem is that pam is used in *every* build environment and so is libtirpc. So if you add further dependencies to libtirpc, you also add more to *every* build environment.
And I don't think that pam requires kerberos - it just doesn't make sense. So I understand that you need that fix for secure NFS mounts, but you don't understand the price tag of that fix. Can we perhaps split either pam or libtirpc's functionality into 2 spec files or do you see any other option?
pam_unix*.so uses libtirpc, presumably for NIS (aka YP) lookup. Do we support kerberos authentication for NIS lookup I wonder. This wasn't a problem before because of libgssglue. This is a wrapper library that maps between libtirpc things and krb5 things. It does some magic run-time loading of krb5 so that isn't a formal dependency on krb5, but if you try any krb5 stuff when krb5 isn't there it will fail. Current krb5 has added support for all the interfaces that libtirpc needs, so libgssglue isn't needed any more. We can still compile both libtirpc and nfs-utils to use libgssglue but that doesn't work either. I think as both krb5 and libgssglue provide the same interfaces (with the same names) and rpc.gssd needs to link to them both, it can get confused and use one interface from one library and on interface from another and it all goes pear-shaped. Upstream doesn't seem interested in libgssglue any more so I don't know how long we will be able to persist with it. I'll have another poke at nfs-utils next week and see if I can make it work with libgssglue. Meanwhile feel free to revert the libtirpc change. I doubt that it is at all easy to split the krb5-accessing part of libtirpc out. Maybe would could split a couple of krb5 libraries out of the krb5 package and only install that package when nfs-utils isn't installed? I think libgssapi_krb5.so.2 libkrb5.so.3 libkrb5support.so.0 would be enough. Does that sound OK? NeilBrown -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIVAwUBUpb2bznsnt1WYoG5AQL2nw//QBFk/Whsus7zcSnzTeer4u7P0Ed9PElr 6g9dfAXqZ2w4vDEsVSiyRCLtwJQkd1R/9sFMXkjzVCfargvbxcKylvEsw2v4Qhni PtAj9imbhOEMqBjLphjTTy6o6lIGqbpHKxlS7jzJzazjIKkEzKHbTrAtZsWYQVNT lA9Apn05uAS6KXCfdwQZT6DJlMeJhqUWwzaU17fmTH5/N40UFU86l+QdzYqt1yVt RlP1xnwx0U66zW3Fu9QHHja8UL2GSuNIxh37doG5rvlAIUeMux/SRiLv3ZkUXXc4 +t/JNj36sQE/KxMFvE5CvmahRkX+t2vsHX1t7h7ZO4L1l4Vh8ZOYGkI8rVqFpSXm DJuqRLcvEbTWPJk8o8NOghDAaZGEXNpMoWOOezJ329g0tzvvEJg5P70yNwl3JbCk pZ6X4uDReZKhBSRVj04QWNXs35tEU4S5gyKSO7y1GAulwDfS66wJ32cjSMUwz56d oPzhrQfc1/JEBE11L3ngWn6ezVeaFxtXzrobUXXNKzWpiVdWvtp9Uh7LuAZBWCWe 02baib8c5zdOz/S3EuJqjDYKk3w5Ar4UO8PL7Vg3cn0E7ggAoe853YsFg4vcb/zo mla2FNTAl8v+e7tKkzvFiyLMbP3oGkamkcPPgbmeZmWLvrGkAgjJflgvD4y4Jroh JyMGjIkDZlM= =EnPW -----END PGP SIGNATURE-----