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