Gentoo Archives: gentoo-dev

From: "Andreas K. Huettel" <dilfridge@g.o>
To: gentoo-dev@l.g.o
Cc: toolchain@g.o, base-system@g.o
Subject: [gentoo-dev] glibc-2.26 and changes with SunRPC, libtirpc, ntirpc, libnsl (NIS and friends), ...
Date: Mon, 18 Sep 2017 09:56:53
Message-Id: 1577962.20ZSkpDzGI@porto
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
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.

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?

(off for a swim now... )

Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)


File name MIME type
signature.asc application/pgp-signature