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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 6E4ED15ACFC for ; Fri, 5 May 2023 16:37:20 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 19097E0A68; Fri, 5 May 2023 16:37:16 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C09DBE09E2 for ; Fri, 5 May 2023 16:37:15 +0000 (UTC) From: Ulrich Mueller To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: Does anyone still rely on the CONF_LIBDIR variable? In-Reply-To: (Ulrich Mueller's message of "Wed, 03 May 2023 21:26:37 +0200") References: Date: Fri, 05 May 2023 18:37:05 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Archives-Salt: f2fe9181-7879-42b9-8869-7e910fe65e02 X-Archives-Hash: 28d31426c35e60fa894bef3b77315705 --=-=-= Content-Type: text/plain >>>>> On Wed, 03 May 2023, Ulrich Mueller wrote: > I wonder about the CONF_LIBDIR variable and the implementation of the > dolib* commands in Portage. These commands normally use the ABI and > LIBDIR_${ABI} variables from the profile to determine the library > directory (e.g. "lib" or "lib64"). > However, if either ABI or LIBDIR_${ABI} happens to be unset, there is a > two-stage fallback in place, first to the value of CONF_LIBDIR, then to > literal "lib" [1]: > LIBDIR_VAR="LIBDIR_${ABI}" > if [[ -n ${ABI} && -n ${!LIBDIR_VAR} ]] ; then > CONF_LIBDIR=${!LIBDIR_VAR} > fi > CONF_LIBDIR=${CONF_LIBDIR:-lib} > AFAICS the CONF_LIBDIR variable had been introduced in the 2004.3 > profile [2], but was replaced already in 2005 by the present > LIBDIR_${ABI} mechanism [3]. CONF_LIBDIR hasn't been assigned in > profiles ever since. > Presently there are some relics of CONF_LIBDIR in Portage's dolib* (see > above) , but it is not used in its econf or get_libdir functions. > Pkgcore doesn't use CONF_LIBDIR at all. PMS defines dolib in yet another > way [4] with an additional CONF_LIBDIR_OVERRIDE variable, which isn't > implemented in either of the two package managers. > Clearly this situation is not ideal, because a) dolib* and get_libdir > are not consistent with each other, and b) PMS, Portage, and Pkgcore > don't agree with each other. > Before we decide on possible ways to proceed with the issue, I want to > ask whether anyone still relies on CONF_LIBDIR for any purpose? > There is also bug 267159 [5] with some more details. Nobody has spoken up, therefore I believe the best way forward is to drop the variable, as suggested in bug 267159 [5] comment #4. I have posted a patch for PMS to gentoo-pms (unfortunately, archives still aren't working, but <20230505161017.7487-1-ulm@gentoo.org> is the Message-Id). A patch for multilib.eclass will follow later. Ulrich > [1] https://gitweb.gentoo.org/proj/portage.git/tree/bin/ebuild-helpers/dolib?h=portage-3.0.47#n25 > [2] https://gitweb.gentoo.org/archive/repo/gentoo-2.git/commit/?id=1482b856ad2a301c8eb2245a7c7265350af2691d > [3] https://gitweb.gentoo.org/archive/repo/gentoo-2.git/commit/?id=054e484d8717a18622615e019e7cd62495365192 > [4] https://projects.gentoo.org/pms/8/pms.html#x1-129001r3 > [5] https://bugs.gentoo.org/267159 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmRVMLEPHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4u5cEIAKEf7Gib1VmhVY0Mb1V8l+7/Z/87xr6PSYPG DKaSDoYGE7lvh5xb1KDvhBZqmw+Uf3xAHaOuXdTQNJ8ZluHLxhw+rtk6ApyRjG4/ C33ghMXY++GTZuBU5Xj202Zk4kui+8X5cuK+M9IyZN9Mxe+CgmEISfzUsVORzrkp aMfqv0IkMh8rOZSxq1X8Hf99CmTUhvuJqiAFvvlA8SzGhCNPqCbArgUPYpIy4OzM OFOyJO4CeUCmUWRaCSddLl+fGUb7FTNVTHRGC3krOQeW/KjF5M875jTG+jC4NfaY eSCA4XExOxLI3pHHXC6zmAl//k8ZIhHMKmPPAusZsIRktt4e0Nw= =qJnG -----END PGP SIGNATURE----- --=-=-=--