Re: glibc/libtirpc and future of client RPC code

[Mike Frysinger <vapier at gentoo dot org>]

On 24 Jun 2015 14:44, Thorsten Kukuk wrote:
> 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.

pretty sure the --disable-obsolete-rpc flag already accomplishes this.  the 
problem is that libtirpc is not a full replacement yet for the API in glibc.

> 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 sunrpc code in glibc should still be under its original license, so i don't 
think moving it over should be a problem.
-mike

Attachment: signature.asc
Description: Digital signature