On 18/09/17 10:56, Andreas K. Huettel wrote:
> So glibc-2.26 is already out for some time, but we still haven't keyworded it 
> yet. Why?
>
> * I want to use the opportunity to make the long-delayed switchover from 
> glibc-internal SunRPC (long deprecated and outdated) to external 
> implementations (libtirpc, and possibly ntirpc).
>
> * The (outdated and deprecated) NIS(YP) and NIS+ support (libnsl) has been 
> removed from glibc (except for a compatibility library that doesnt install 
> headers), and is now provided by net-libs/libnsl (increased soversion).
>
> This mail is mainly about how to best structure the transition.
> Comments, suggestions, corrections, feedback welcome.
>
> 1) About RPC. 
>
> AFACIS there are three implementations:
> a) SunRPC, headers in /usr/include, code provided by glibc
> b) net-libs/libtirpc, headers in /usr/include/libtirpc, library -l tirpc
> c) (?) net-libs/ntirpc, headers in /usr/include/ntirpc, library -l ntirpc
>
> Option a) is going away with sys-libs/glibc-2.26-r1. 
> Options b) and c) may in addition need headers from net-libs/rpcsvc-proto
> I haven't done any testing with c) yet, will do so.
> a), b), and c) are co-installable.
>
> My suggestion for an ideal implementation would be that any package that uses 
> RPC defines useflags:
> sunrpc - build against glibc
> libtirpc - build against net-libs/libtirpc
> ntirpc - build against net-libs/ntirpc
> with 
> REQUIRED_USE="^^ ( sunrpc libtirpc ntirpc )"
> If rpc support is optional with useflag rpc, then this becomes
> REQUIRED_USE="rpc? ( ^^ ( sunrpc libtirpc ntirpc ) )"
>
> Since the three options are coinstallable I see no problems with a package 
> only supporting a subset, but I have no clue how this interacts at runtime.
>
> Of course this "ideal option" is also the most work-intensive.
<snip>

Would a virtual help any? Probably overlooking a good number of factors,
but wasn't mentioned yet ...

MJE