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 3D6591396D0 for ; Tue, 19 Sep 2017 20:38:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id ADF9C1FC11B; Tue, 19 Sep 2017 20:38:24 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 4F3011FC008 for ; Tue, 19 Sep 2017 20:38:24 +0000 (UTC) Received: from eris.local (dynamic-adsl-84-220-165-32.clienti.tiscali.it [84.220.165.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id 567BE33BF43; Tue, 19 Sep 2017 20:38:20 +0000 (UTC) Subject: [gentoo-dev] Re: glibc-2.26 and changes with SunRPC, libtirpc, ntirpc, libnsl (NIS and friends), ... To: "Andreas K. Huettel" , gentoo-dev@lists.gentoo.org Cc: toolchain@gentoo.org, base-system@gentoo.org References: <1577962.20ZSkpDzGI@porto> From: Luca Barbato Message-ID: <13cb1de2-e252-13d9-fa47-1133d85b42e2@gentoo.org> Date: Tue, 19 Sep 2017 22:38:17 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:56.0) Gecko/20100101 Thunderbird/56.0 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 In-Reply-To: <1577962.20ZSkpDzGI@porto> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: 84372b33-ffc7-4a9e-a647-51aa5aecf304 X-Archives-Hash: 3488d67690a7b8743a1d1f163b1e7c1f 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 > || ( > 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