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

[Steve Dickson <SteveD@redhat.com>]

Chuck Lever wrote:
>>
>>>>
>>>>> I guess I just don't see why there has to be two switches for
>>>>> this feature...
>>>>
>>>> Because people seem to want to disable IPv6 support completely on their
>>>> systems...  Because there is a striking lack of infrastructure for IPv6
>>>> support (including GUIs for configurating ip6tables, lack of IPv6
>>>> support in NetworkManager, no IPv6 support in tcp_wrappers,
>>>> inability to
>>>> disable IPv6 support in the kernel without hacking it out of
>>>> /etc/modprobe.conf, and so on)...  Because TI-RPC is one level of
>>>> complexity, and IPv6 adds more complexity...
>>>>
>>>> We can probably remove --enable-ipv6, and just stick with
>>>> --enable-tirpc, which implies IPv6 support, if you prefer that.
>>> Actually I would like to do just the opposite... remove --enable-tirpc
>>> and stick with --enable-ipv6...
>>>
>>>> But it's a strange argument, when we have --enable-mount,
>>>> --enable-nfsv4,
>>>> and on and on.
>>> Well, your examples are all defining functionality... not libraries...
>>>
>>
>> Right. I agree with Steve here. I think it makes sense to keep the
>> knobs we expect people to twiddle to be for features and not
>> necessarily for libs.
> 
> I really don't understand why having TI-RPC in a library is important here.
> 
> --enable-tirpc is a feature knob.  Forget that it happens to be in a
> library.  Either nfs-utils supports TI-RPC or it supports legacy RPC. 
> The external behavior of nfs-utils changes.
> 
> Legacy RPC is in a library too.  It happens to be in a library that is
> included by default, so configure doesn't have to figure out where RPC
> support is and whether it is installed.
> 
> What's the difference?
Following this theory there should have been an --enable-glibc
which obviously misguided... 

All configuration flags define functionality not supporting parts 
of those functionalities.... 

Lets just have an --enable-ipv6/--disable-ipv6 flag and leave it to
the distros as to how they want to deal with it. 

Now with that said, just because --enable-ipv6 is set, does not have 
to mean *all* IPv6 support is there, especially if its not fully baked.
More times that not, pieces of major new features are released in 
multi updates... Maybe in this first IPv6 release only the supporting 
components are enabled (ala libtirpc). In the next release client 
side rpc.statd is enabled and so on... 

Trickling things in a very slow and control pace makes it much easier 
to manage new functionality... IMHO... and having the big hammer
(ala --disable-ipv6) is a comfortable thing when comes to maintaining  
stability...

steved.