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

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]

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 ;)

> > > 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]