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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

-- 
Jeff Layton <jlayton@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux