[gentoo-dev] Does anyone still rely on the CONF_LIBDIR variable?

[gentoo-dev] Does anyone still rely on the CONF_LIBDIR variable?

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]

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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

[gentoo-dev] Re: Does anyone still rely on the CONF_LIBDIR variable?

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 2334 bytes --]

>>>>> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

[gentoo-dev] [PATCH] multilib.eclass: Drop CONF_LIBDIR

[Ulrich Müller]

The CONF_LIBDIR variable was used exclusively in the 2004.3 profile
(i.e. it was no longer defined in 2005.0), before the ABI and
LIBDIR_${ABI} variables existed.

Simply use "lib" as default, which is consistent with get_libdir().

Bug: https://bugs.gentoo.org/267159
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
---
 eclass/multilib.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
index 4a6e4160d5cb..77340a23e30f 100644
--- a/eclass/multilib.eclass
+++ b/eclass/multilib.eclass
@@ -26,7 +26,7 @@ export CFLAGS_default
 export LDFLAGS_default
 export CHOST_default=${CHOST_default:-${CHOST}}
 export CTARGET_default=${CTARGET_default:-${CTARGET:-${CHOST_default}}}
-export LIBDIR_default=${CONF_LIBDIR:-"lib"}
+export LIBDIR_default="lib"
 export KERNEL_ABI=${KERNEL_ABI:-${DEFAULT_ABI}}
 
 # @FUNCTION: has_multilib_profile
-- 
2.40.1