Re: should we make --enable-tirpc the default in current nfs-utils?

[Steve Dickson <SteveD@redhat.com>]

Chuck Lever wrote:
> 
> I think you are making my argument for me.  The fact that TI-RPC support
> could go into glibc (but hasn't because of politics) suggests that
> --enable-tirpc has nothing to do with a particular library.  It is
> solely a feature knob, just like all the other --enable switches in
> ./configure.
So you agree that --enable-tirpc and --enable-ipv6 are the same thing
since you can't have ipv6 without libtirpc and only reason to
have libtirpc is ipv6...

> 
>>> I honestly don't see a distinction between --enable-gss, which adds
>>> additional features in nfs-utils, but requires an additional library,
>>> and --enable-tirpc, which adds additional features, but requires an
>>> additional library.
>> -enable-gss cause two daemon to be build and get installed which
>> adds the Secure NFS functionality. --enable-tirpc only causes code
>> paths to change, it add no functionality unless Ipv6 is enabled.
> 
> TI-RPC is not just an IPv6 enabler.  It also has interoperability
> implications.  Support for rpcbind v3/v4 has no dependence on IPv6.  You
> can use rpcbind v3 or v4 requests over IPv4, for example, which provides
> a significantly richer set of functionality.  One area of non-IPv6
> interest would be support for registering local services via AF_UNIX --
> this type of registering is actually authenticated, so it is a good
> security feature.
But again, the only reason rpcbind is around is because it has 
IPv6 support. Please believe, I was a bit nervous switch out the 
portmapper since it was a very stable piece of code since it
very rarely changed... 
 
> 
>> So that's way I think all that is needed is an --enable-ipv6 flag.
> 
> Actually, the new statd is built only if --enable-tirpc is set.  So,
> yes:  new code _and_ new components are provided if --enable-tirpc is
> set.  TI-RPC is very similar to Secure NFS functionality.  Secure NFS
> provides support for new RPC features known as RPCSEC GSS, and
> --enable-tirpc provides support for new RPC features known as TI-RPC. 
> So again, I don't see any philosophical difference between --enable-gss
> and --enable-tirpc.
And the only reason statd need to use the new code is for IPv6 
support, true? 

> 
> However, --enable-ipv6 is unnecessary because we want, and have,
> run-time switches for that support.  We are forced to, because nfs-utils
> has to run on kernels which may or may not support IPv6.

> 
> I am continuing to argue this point because getting rid of
> --enable-tirpc will make our jobs a lot harder.  The reason this knob is
> there is to firewall the new code and keep upstream nfs-utils stable as
> we integrate more and more support for TI-RPC.
Understood... And I applaud the effort both you and Jeff are making...

> 
> If we call it --enable-ipv6, many distributions will say "so what, i
> don't need that" and leave it turned off.  We won't get the kind of soak
> time we really need.
And if we call --enable-tirpc they will not know that they are enabling 
IPv6 code in statd, true?

But in the end, I guess I have confidence that the distros will do what is 
best for them... and if they have customers that need this support they 
will enable it. If not, they will not enable it, regardless of what 
upstream does...

steved.