public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ulrich Mueller <ulm@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: Does anyone still rely on the CONF_LIBDIR variable?
Date: Fri, 05 May 2023 18:37:05 +0200	[thread overview]
Message-ID: <u7ctmwx8u@gentoo.org> (raw)
In-Reply-To: <u5y991aj6@gentoo.org> (Ulrich Mueller's message of "Wed, 03 May 2023 21:26:37 +0200")

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

  reply	other threads:[~2023-05-05 16:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-03 19:26 [gentoo-dev] Does anyone still rely on the CONF_LIBDIR variable? Ulrich Mueller
2023-05-05 16:37 ` Ulrich Mueller [this message]
2023-05-06 15:13   ` [gentoo-dev] [PATCH] multilib.eclass: Drop CONF_LIBDIR Ulrich Müller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=u7ctmwx8u@gentoo.org \
    --to=ulm@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox