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

[Thorsten Kukuk <kukuk at suse dot de>]

On Thu, Jun 25, Chuck Lever wrote:

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

Yes, that's currently my prefered solution, too.
libnss_nis and libnss_nisplus needs to be a drop in replacement,
libnsl could have a higher version number and be installed
in parallel.
This would mean we would need a switch to disable building
the nis directory in glibc, or at least to disable building
and installing libnss_nis and libnss_nisplus and installing
the libnsl header files.

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

grep for "YP".
Currently I see src/netnamer.c, src/getrpcent.c, src/getpublickey.c.

netnamer.c: Lookup of /etc/netid via NIS. Don't know if we need that.

src/getrpcent.c: We use the glibc function already if available, don't
know on which OS we compile our own version.

src/getpublickey.c: Similar to netnamer.c: lookup of publickeys
in NIS maps, not only local.

That code is needed for auth_des, so we cannot move it in another library.

  Thorsten

> > And are there more subsystems into glibc,
> > which currently use SunRPC but who would benefit from TI-RPC?
> 
> 
> --
> Chuck Lever
> chucklever@gmail.com
> 
> 

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