This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Thorsten Kukuk <kukuk at suse dot de>
- Cc: Chuck Lever <chucklever at gmail dot com>, libc-alpha at sourceware dot org, libtirpc List <libtirpc-devel at lists dot sourceforge dot net>
- Date: Thu, 25 Jun 2015 20:37:25 +0200
- Subject: Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code
- Authentication-results: sourceware.org; auth=none
- References: <20150624124457 dot GA7930 at suse dot de> <879047F3-9559-4D45-839D-F047AB65C7E3 at gmail dot com> <20150625153358 dot GB858 at suse dot de>
On Thu, Jun 25, 2015 at 05:33:58PM +0200, Thorsten Kukuk wrote:
> 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?
>
That would be nice. As glibc libnns_nis are in maintainance mode if you
could make stable replacement we would welcome removing these and
telling distros to add dependency on your library for future version.