From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 8745F1396D0 for ; Mon, 18 Sep 2017 09:56:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2CF87E0ECB; Mon, 18 Sep 2017 09:56:47 +0000 (UTC) Received: from mo6-p05-ob.smtp.rzone.de (mo6-p05-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5305::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B6B95E0EBE for ; Mon, 18 Sep 2017 09:56:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1505728605; s=domk; d=akhuettel.de; h=Content-Type:MIME-Version:Date:Subject:Cc:To:From; bh=2tcJGVnn/nsphNsv4hvaMl3QFjadc7FJmwZhSlUWl1A=; b=pTprEy32tw0KklxrHyXP70isvIt8Q9qsmVlEO3el/6xotrf2Qd1MsPl5LtP+bDtvSJ 24Tq+KW6U6l/MjZOhHPwZQdBsoVrbO+tdW/NdpoX5ZqKlTzQoBnlHppyMXKUzFE5zuzK Vgscg12OE/AENLSbPqXp/ffUgc2PGvo65KhG4= X-RZG-AUTH: :IW0NeWCpcPchHrcnS4ebzBgQnKHTmUiSF2JlOcyy9p4ooijp4yU1/Vq6pg== X-RZG-CLASS-ID: mo05 Received: from porto.localnet (112.59.202.88.dynamic.sat.abo.nordnet.fr [88.202.59.112]) by smtp.strato.de (RZmta 41.4 DYNA|AUTH) with ESMTPSA id V03e89t8I9ufzEM (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Mon, 18 Sep 2017 11:56:41 +0200 (CEST) From: "Andreas K. Huettel" To: gentoo-dev@lists.gentoo.org Cc: toolchain@gentoo.org, base-system@gentoo.org Subject: [gentoo-dev] glibc-2.26 and changes with SunRPC, libtirpc, ntirpc, libnsl (NIS and friends), ... Date: Mon, 18 Sep 2017 11:56:30 +0200 Message-ID: <1577962.20ZSkpDzGI@porto> Organization: Gentoo Linux Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart12764989.s5JL5MF40X"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Archives-Salt: a27af173-5f90-4578-aafb-2cc8fbc67b4e X-Archives-Hash: 034dbef0c206eba696c47c4daf2c7ce8 --nextPart12764989.s5JL5MF40X Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" So glibc-2.26 is already out for some time, but we still haven't keyworded = it=20 yet. Why? * I want to use the opportunity to make the long-delayed switchover from=20 glibc-internal SunRPC (long deprecated and outdated) to external=20 implementations (libtirpc, and possibly ntirpc). * The (outdated and deprecated) NIS(YP) and NIS+ support (libnsl) has been= =20 removed from glibc (except for a compatibility library that doesnt install= =20 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.=20 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.=20 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 us= es=20 RPC defines useflags: sunrpc - build against glibc libtirpc - build against net-libs/libtirpc ntirpc - build against net-libs/ntirpc with=20 REQUIRED_USE=3D"^^ ( sunrpc libtirpc ntirpc )" If rpc support is optional with useflag rpc, then this becomes REQUIRED_USE=3D"rpc? ( ^^ ( sunrpc libtirpc ntirpc ) )" Since the three options are coinstallable I see no problems with a package= =20 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 mea= ns=20 pointing it to the right include directory (at compile time) and library na= me=20 (at link time); if that's not done, a build fails because the rpc headers=20 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.=20 b) An updated and much improved implementation is provided by net-libs/libn= sl,=20 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/libns= l=20 requires at least our glibc-2.26 (otherwise you get file collisions). Porting a package means adding a dependency in the style of=20 || (