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

["J. Bruce Fields" <bfields@fieldses.org>]

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.

--b.