Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code

[Chuck Lever <chucklever at gmail dot com>]

> On Jun 24, 2015, at 8:44 AM, Thorsten Kukuk <kukuk@suse.de> wrote:
> 
> 
> Hi,
> 
> that's a mail for RFC, advice, ideas, or however you want to
> call it.
> And since it affects glibc and libtirpc, I decided to do a crosspost
> on both developer mailing lists.
> 
> Last year I implemented the NIS protocol for IPv6. With libtirpc,
> this was no problem on server side, ypserv/ypbind are working fine.
> 
> But now I run into a lot of problems on the client side.
> In the end, this step is quite easy: link the NIS client code
> against libtirpc and this is it more or less. The public
> interfaces of the client code will stay the same, no API or
> ABI changes. The only difference is, that suddenly all applications
> using this interfaces can speak with a IPv6 NIS server.
> But: the NIS client code is part of glibc, which only comes
> with the IPv4 only SunRPC implementation.
> 
> So the NIS client code (libnsl, libnss_nis.so, libnss_nisplus.so)
> from glibc needs to be moved somewhere else and somehow we need to
> be able to disable that code in glibc then, or at least make it
> runtime only.
> 
> Since libtirpc has code calling YP and NIS+ functions, which are
> currently disabled, moving it to libtirpc would be one choice. But
> I don't know if we don't run into a license conflict here between the
> glibc and tirpc licenses. The second disadvantage is that this would
> mean to touch all applications linked against libnsl and calling
> yp_*() functions. That's something I want to avoid.
> 
> The second solution I see is, to move libnsl, libnnss_nis and 
> libnss_nisplus to an own project independent of glibc and link
> them against libtirpc. I have already a working proof of
> concept, so that's not a problem.
> We could use the same soname for libnsl, and we wouldn't even
> need to recompile any client library. Or we could bump the
> version number and need to recompile, both would be ok for me.
> But I would like to avoid to find another name for that library,
> since this means, touching all configure files of all applications
> using NIS. I tried that as first, but gave up since this is not
> really doable.
> 
> 
> What are your opinions? Or do you see even another solution
> for this problem?

I like the second solution: move YP/NIS/NIS+ to one or more
separate upstream projects, and package them independently of
glibc and libtirpc.

What code in libtirpc calls on YP and NIS+ ? Should that be
moved as well?

> And are there more subsystems into glibc,
> which currently use SunRPC but who would benefit from TI-RPC?


--
Chuck Lever
chucklever@gmail.com