glibc/libtirpc and future of client RPC code

[Thorsten Kukuk <kukuk at suse dot de>]

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? And are there more subsystems into glibc,
which currently use SunRPC but who would benefit from TI-RPC?

Thanks,
  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)