On 18/09/2017 11: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
So this one is transient.
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.
If they aren't ABI-compatible you would expect explosions once you link
two libraries linked to the two different implementation (assuming they
aren't macro-mangling everything).
Of course this "ideal option" is also the most work-intensive.
Both libtirpc and ntirpc supply a packageconfig file. Porting a package means
pointing it to the right include directory (at compile time) and library name
(at link time); if that's not done, a build fails because the rpc headers
cannot be found.
(In my @system chroot, python fails atm.)
2) About YP / NIS / NIS+.
a) The old libnsl implementation is provided by glibc, soversion 1.
b) An updated and much improved implementation is provided by net-libs/libnsl,
soversion 2.
glibc-2.26 installs only the library for a), and no headers.
Since I dont want to mess with currently used glibc ebuilds, net-libs/libnsl
requires at least our glibc-2.26 (otherwise you get file collisions).
Porting a package means adding a dependency in the style of
|| ( <sys-libs/glibc-2.26 net-libs/libnsl )
It may not always be obvious where this is needed, since net-libs/libnsl is
already pulled in deep in the dependency tree (my @system chroot has it).
So... that's it for the moment.
Comments, ideas?
Beside making sure the providers are mix-and-matchable w/out pain sounds
good.
We could check if the other libc could be switched to the external
provider and play the lazy card and just always force an external
implementation.
lu
