Mailinglist Archive: opensuse-packaging (174 mails)

< Previous Next >
[opensuse-packaging] Re: krb5 dependency in Base:System
  • From: NeilBrown <neilb@xxxxxxx>
  • Date: Thu, 28 Nov 2013 18:53:19 +1100
  • Message-id: <20131128185319.40934363@notabene.brown>
Hash: SHA1

On Thu, 28 Nov 2013 06:46:05 +0100 Stephan Kulow <coolo@xxxxxxx> wrote:

Hash: SHA1

Am 27.11.2013 23:25, schrieb NeilBrown:
On Wed, 27 Nov 2013 19:20:45 +0100 Stephan Kulow <coolo@xxxxxxx>


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

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
would be enough.

Does that sound OK?

Version: GnuPG v2.0.22 (GNU/Linux)

< Previous Next >