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

Chuck Lever
2009-06-05T16:15:14Z

On Jun 5, 2009, at 12:10 PM, J. Bruce Fields wrote:

> On Fri, Jun 05, 2009 at 07:36:48AM -0400, Jeff Layton wrote:
>> Eventually, we most distros are going to want to build nfs-utils
>> against libtirpc in order to get IPv6 support. At some point, we'll
>> probably want to make building with IPv6 support the default. In the
>> meantime however, we need to get more testing exposure for the TI-RPC
>> codepaths. We'll probably start building Fedora's nfs-utils with TI-
>> RPC
>> support in the near future.
>>
>> The question that Steve D. has asked is whether we should also make
>> --enable-tirpc the default for the mainline nfs-utils tree?
>>
>> Doing this now would add wider testing exposure for these codepaths
>> and
>> help flush out bugs in TIRPC+IPV4 codepaths. OTOH, it means adding a
>> new library dependency for packagers, or they'll need to take the
>> conscious step to --disable-tirpc when they configure.
>>
>> We could make it so that configure looks for libtirpc and if it's not
>> available, configures the build against legacy RPC interfaces. I
>> think
>> this is a bad idea however. While it should "just work" either way,
>> there are some small behavioral differences when TIRPC support is
>> built
>> in. I think it's probably better to make enabling and disabling
>> TIRPC a
>> conscious step.
>>
>> Thoughts?
>
> Makes sense to me to have upstream defaults set to what we expect
> distributions to move to, assuming there aren't known regressions.

That's a big assumption, and it's exactly why we wanted to have some
soak time in rawhide or Debian unstable before enabling it by default
upstream.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com