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

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

On Fri, Jun 05, 2009 at 12:14:48PM -0400, Chuck Lever wrote:
>
> 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,

I'm confused--there are known regressions or there aren't.  (I'm not
talking about unknown regressions....)

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

I don't think upstream needs to be more conservative than the
development distro's.

--b.