[Libtirpc-devel] Fwd: Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

[Andrew J. Schorr]

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