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
signature.asc
Description: OpenPGP digital signature
