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

[Steve Dickson <SteveD@redhat.com>]

Jeff Layton wrote:
> On Mon, 08 Jun 2009 05:09:36 -0400
> Steve Dickson <SteveD@redhat.com> wrote:
> 
>>
>> Jeff Layton wrote:
>>> On Sat, 6 Jun 2009 11:00:41 -0700
>>> "Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:
>>>
>>>>  
>>>>
>>>>> -----Original Message-----
>>>>> From: Jeff Layton [mailto:jlayton@redhat.com] 
>>>>> Sent: Saturday, June 06, 2009 4:12 AM
>>>>> To: Mike Frysinger
>>>>> Cc: linux-nfs@vger.kernel.org
>>>>> Subject: Re: should we make --enable-tirpc the default in 
>>>>> current nfs-utils?
>>>>>
>>>>> On Fri, 5 Jun 2009 16:50:41 -0400
>>>>> Mike Frysinger <vapier@gentoo.org> wrote:
>>>>>
>>>>>> On Friday 05 June 2009 13:36:34 Jeff Layton wrote:
>>>>>>> On Fri, 5 Jun 2009 12:24:39 -0400 Mike Frysinger wrote:
>>>>>>>> On Friday 05 June 2009 07:36:48 Jeff Layton wrote:
>>>>>>>>> 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.
>>>>>>>> or have the configure script dump a warning whenever 
>>>>> libtirpc is 
>>>>>>>> not used ...
>>>>>>> The problem there is that these sorts of warnings tend to 
>>>>> get lost 
>>>>>>> in the noise. So then you have the situation where people aren't 
>>>>>>> sure whether they built against libtirpc or not. Only running ldd 
>>>>>>> against the binaries will tell you.
>>>>>> the configure script knows whether it's going to be 
>>>>> building against libtirpc.  
>>>>>> it isnt going to happen randomly during `make`.
>>>>>> AC_MSG_WARNING([
>>>>>>
>>>>>> You really should think about switching to libtirpc
>>>>>>
>>>>>> ])
>>>>>>
>>>>>> maybe it's different in Gentoo, but people report configure 
>>>>> warnings 
>>>>>> all the time ;)
>>>>>>
>>>>> Well, Gentoo probably has a larger percentage of people 
>>>>> compiling the sources. Other distros generally distribute the 
>>>>> binaries. But to be fair, it's not unreasonable to expect 
>>>>> people who are compiling from sources to know what they're doing.
>>>>>
>>>>>>>>> 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.
>>>>>>>> i think this is the correct behavior for unspecified configure 
>>>>>>>> flags
>>>>>>> In general, yes. In this case though I think it's reasonable to 
>>>>>>> force people compiling the package without tirpc 
>>>>> installed to take 
>>>>>>> the conscious step to either install the right libs and 
>>>>> headers, or 
>>>>>>> to add --disable-tirpc.
>>>>>>>
>>>>>>> I think doing so will lead to a more deterministic 
>>>>> outcome in this 
>>>>>>> situation. If that's a problem however, I'm willing to 
>>>>> listen to the 
>>>>>>> reasoning and reconsider...
>>>>>> i just dont agree with having to re-run configure to "fix" 
>>>>> a condition 
>>>>>> that the configure script should already be able to handle. 
>>>>>  but i'm 
>>>>>> speaking in general terms here, not specific to what you propose as 
>>>>>> that isnt exactly the same thing.  i dont feel too strongly here, 
>>>>>> especially since it doesnt affect me in any realistic way.
>>>>>> -mike
>>>>> Ok, fair enough. I don't feel terribly strongly about this 
>>>>> either and that is the the conventional way that configure 
>>>>> options work (don't fail unless absolutely necessary). I'll 
>>>>> see about coding up a patch that makes --enable-tirpc the 
>>>>> default but falls back to legacy RPC code with a warning if 
>>>>> TIRPC libs/headers aren't present.
>>>> Changing the default because the code isn't sufficiently tested strikes
>>>> me as a particularly bad idea.  If Red Hat wants more testing,
>>>> distribute nfs-utils with TIRPC enabled in Fedora, and _then_ change the
>>>> default in nfs-utils after more testing has occurred.  Delegating
>>>> testing to unsuspecting end-users (especially people who need to rebuild
>>>> in production environments) seems like an ideal way to cause real
>>>> problems.
>>>>
>>> If users have TIRPC installed on their systems, why would we want to
>>> avoid using it? Pieces of this code (mount.nfs, for instance) are
>>> pretty much complete and working. There's no real reason to build these
>>> apps against legacy RPC now if we can help it.
>>>
>>>> And ffs, don't change the existing configure behavior.  When nfs-utils
>>>> is supposed to build with TIRPC (e.g., when TIRPC is the default), the
>>>> configure should fail if TIRPC isn't installed.  Perhaps the error
>>>> message on failure could suggest running configure with --disable-tirpc.
>>>>
>>> nfs-utils is already builds with TIRPC. It also builds with legacy RPC.
>>> So in this discussion the first question is, "Is there some reason to
>>> not build against TIRPC when it's available on the machine?"
>>>
>>> Second question: "Should make configure bail out when TIRPC isn't
>>> available and force the user to specify --disable-tirpc on the command
>>> line, or should we make the build just fall back to legacy RPC when the
>>> right TIRPC libs/headers aren't present?"
>>>
>>> So far, I'm leaning toward "No" on the first question and to
>>> "automatically fall back" on the second question.
>> I concur on this approach... but would like to change the flavour a bit
>> Meaning.. Lets take out any and all references to TIRPC and replace
>> them with IPv6 support, since, ultimately, that's what were are talking
>> about...
>>
>> So, if libtirpc exists, there will be IPv6 support. If not, there will
>> not be IPv6 support... 
>>
> 
> Yes, eventually we'll want to make IPv6 support default to "on" when
> TIRPC is present. If you look at the code though, there are #ifdef's
> for HAVE_LIBTIRPC and IPV6_SUPPORTED. These are currently controlled by
> separate configure options, but you cannot build in IPv6 support
> without TIRPC.
> 
> In the interest of phasing in this support slowly, Chuck and I are
> proposing that we enable TIRPC by default now, and keep IPv6 support a
> separate option for the time being. Eventually, we'll want to turn on
> IPv6 support automatically when TIRPC is available.  I think it makes
> sense though to wait until we have some experience with TIRPC support
> in nfs-utils before we go all the way with turning on IPv6 support by
> default.
> 
Is there *any* IPv6 code working at all? We can always call the
support "experimental" until you guys are done... 

I guess I just don't see why there has to be two switches for
this feature... 

steved.