From: "J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: should we make --enable-tirpc the default in current nfs-utils?
Date: Fri, 5 Jun 2009 12:10:27 -0400
Message-ID: <20090605161027.GF10975@fieldses.org>
References: <20090605073648.5a5497b5@tlielax.poochiereds.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-nfs@vger.kernel.org
To: Jeff Layton <jlayton@redhat.com>
In-Reply-To: <20090605073648.5a5497b5-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
Sender: linux-nfs-owner@vger.kernel.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.