| 1 |
So glibc-2.26 is already out for some time, but we still haven't keyworded it |
| 2 |
yet. Why? |
| 3 |
|
| 4 |
* I want to use the opportunity to make the long-delayed switchover from |
| 5 |
glibc-internal SunRPC (long deprecated and outdated) to external |
| 6 |
implementations (libtirpc, and possibly ntirpc). |
| 7 |
|
| 8 |
* The (outdated and deprecated) NIS(YP) and NIS+ support (libnsl) has been |
| 9 |
removed from glibc (except for a compatibility library that doesnt install |
| 10 |
headers), and is now provided by net-libs/libnsl (increased soversion). |
| 11 |
|
| 12 |
This mail is mainly about how to best structure the transition. |
| 13 |
Comments, suggestions, corrections, feedback welcome. |
| 14 |
|
| 15 |
1) About RPC. |
| 16 |
|
| 17 |
AFACIS there are three implementations: |
| 18 |
a) SunRPC, headers in /usr/include, code provided by glibc |
| 19 |
b) net-libs/libtirpc, headers in /usr/include/libtirpc, library -l tirpc |
| 20 |
c) (?) net-libs/ntirpc, headers in /usr/include/ntirpc, library -l ntirpc |
| 21 |
|
| 22 |
Option a) is going away with sys-libs/glibc-2.26-r1. |
| 23 |
Options b) and c) may in addition need headers from net-libs/rpcsvc-proto |
| 24 |
I haven't done any testing with c) yet, will do so. |
| 25 |
a), b), and c) are co-installable. |
| 26 |
|
| 27 |
My suggestion for an ideal implementation would be that any package that uses |
| 28 |
RPC defines useflags: |
| 29 |
sunrpc - build against glibc |
| 30 |
libtirpc - build against net-libs/libtirpc |
| 31 |
ntirpc - build against net-libs/ntirpc |
| 32 |
with |
| 33 |
REQUIRED_USE="^^ ( sunrpc libtirpc ntirpc )" |
| 34 |
If rpc support is optional with useflag rpc, then this becomes |
| 35 |
REQUIRED_USE="rpc? ( ^^ ( sunrpc libtirpc ntirpc ) )" |
| 36 |
|
| 37 |
Since the three options are coinstallable I see no problems with a package |
| 38 |
only supporting a subset, but I have no clue how this interacts at runtime. |
| 39 |
|
| 40 |
Of course this "ideal option" is also the most work-intensive. |
| 41 |
|
| 42 |
Both libtirpc and ntirpc supply a packageconfig file. Porting a package means |
| 43 |
pointing it to the right include directory (at compile time) and library name |
| 44 |
(at link time); if that's not done, a build fails because the rpc headers |
| 45 |
cannot be found. |
| 46 |
(In my @system chroot, python fails atm.) |
| 47 |
|
| 48 |
2) About YP / NIS / NIS+. |
| 49 |
|
| 50 |
a) The old libnsl implementation is provided by glibc, soversion 1. |
| 51 |
b) An updated and much improved implementation is provided by net-libs/libnsl, |
| 52 |
soversion 2. |
| 53 |
|
| 54 |
glibc-2.26 installs only the library for a), and no headers. |
| 55 |
Since I dont want to mess with currently used glibc ebuilds, net-libs/libnsl |
| 56 |
requires at least our glibc-2.26 (otherwise you get file collisions). |
| 57 |
|
| 58 |
Porting a package means adding a dependency in the style of |
| 59 |
|| ( <sys-libs/glibc-2.26 net-libs/libnsl ) |
| 60 |
|
| 61 |
It may not always be obvious where this is needed, since net-libs/libnsl is |
| 62 |
already pulled in deep in the dependency tree (my @system chroot has it). |
| 63 |
|
| 64 |
|
| 65 |
So... that's it for the moment. |
| 66 |
Comments, ideas? |
| 67 |
|
| 68 |
Cheers, |
| 69 |
Andreas |
| 70 |
(off for a swim now... https://www.instagram.com/p/BZLJn1qF09B/ ) |
| 71 |
|
| 72 |
|
| 73 |
-- |
| 74 |
Andreas K. Hüttel |
| 75 |
dilfridge@g.o |
| 76 |
Gentoo Linux developer (council, perl, libreoffice) |
Archives