This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [Libtirpc-devel] Fwd: Re: proposed patch to rpcbind to providefiner-grained security controls than offered by the -i option
- From: "Andrew J. Schorr" <ajschorr at alumni dot princeton dot edu>
- To: Chuck Lever <chucklever at gmail dot com>
- Cc: Steve Dickson <SteveD at redhat dot com>, libc-alpha at sourceware dot org,libtirpc <libtirpc-devel at lists dot sourceforge dot net>
- Date: Mon, 13 Dec 2010 11:39:17 -0500
- Subject: Re: [Libtirpc-devel] Fwd: Re: proposed patch to rpcbind to providefiner-grained security controls than offered by the -i option
- References: <4D0632C5.1040107@RedHat.com><AANLkTi=FNANqAs5m3xbZcQq5K0vMtZBb1+KU9pWC9K8_@mail.gmail.com>
On Mon, Dec 13, 2010 at 10:29:54AM -0500, Chuck Lever wrote:
...
> In short, I think deprecating the legacy RPC API in the glibc headers
> would unnecessarily confuse developers, especially if the libtirpc RPC
> headers take the place of the glibc RPC headers under /usr/include.
Just to be clear, I was recommending deprecating the legacy API only
if the packages continue to be installed the current way. In other
words, deprecate the legacy API in /usr/include/rpc/*.h, but not
in /usr/include/tirpc. Of course, if the legacy header files in
/usr/include/rpc are replaced with the new TIRPC implementation, then
deprecation would make no sense.
The point of deprecating the old headers in /usr/include/rpc would be to alert
developers that they need to port their code to the new (albeit mostly
compatible) API in /usr/include/tirpc.
Regards,
Andy