Algorithm 4 on page 49 of the pms [1] specifies that the variable CONF_LIBDIR_OVERRIDE unconditionally overrides the directory used by the doins* functions. portage-2.1.6.7 seems to ignore the variable, as evidenced by the fact that no source file in portage refers to the variable, and that it mis-installs the libraries from the recently updated nvidia-cuda-toolkit-2.1 ebuild into /opt/cuda/lib64 instead of /opt/cuda/lib due to the fix in bug 265722. A simple grep of the portage tree reveals the only other place the variable is referenced is from the multilib eclass, the nvidia-cuda-toolkit ebuild is likely the only main tree ebuild affected by the mismatch between portage and the pms. [1] numbers accurate as of git checkout 5d64265fe623adf6346ea2793e55ec0e57869dbf
to be precise, this is about algorithm 10 https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-136001r10 which is used for dolib, dolib.so, dolib.a and einstall, afais
Looks like Portage never supported CONF_LIBDIR_OVERRIDE, so I wonder how it ended up in PMS. Maybe we should drop it from the spec? Not entirely sure what is going on with the DEFAULT_ABI variable (also mentioned in PMS algorithm 12.3), but AFAICS Portage only uses it for ccache/distcc, but not in dolib or einstall. Also, why do we have three different algorithms (12.2, 12.3, and 12.5) for determining the library directory?
I think the following reflects what dolib* actually does (I don't care about einstall at this point). It is identical to algorithm 12.5 ("get_libdir logic") except for the additional CONF_LIBDIR quirk at the beginning. \IF{CONF_LIBDIR is set in the environment} \STATE let libdir=the value of CONF_LIBDIR \ELSE \STATE let libdir=\t{lib} \ENDIF \IF{the ABI environment variable is set} \STATE let libvar=LIBDIR_\$ABI \IF{the environment variable named by libvar is set} \STATE let libdir=the value of the variable named by libvar \ENDIF \ENDIF \STATE return the value of libdir
(In reply to Ulrich Müller from comment #2) > Looks like Portage never supported CONF_LIBDIR_OVERRIDE, so I wonder how it > ended up in PMS. Maybe we should drop it from the spec? That seems reasonable to me. > Not entirely sure what is going on with the DEFAULT_ABI variable (also > mentioned in PMS algorithm 12.3), but AFAICS Portage only uses it for > ccache/distcc, but not in dolib or einstall. DEFAULT_ABI is used in multilib.eclass and multilib-build.eclass. These eclasses alter the ABI variable, and they need some way to keep track of which abi is the "default". Portage seems to assume that ABI will always be set before dolib or einstall are called. > Also, why do we have three different algorithms (12.2, 12.3, and 12.5) for > determining the library directory? 12.2 (econf) and 12.5 (get_libdir) are basically the same algorithm. The only difference is we don't pass --libdir to econf if ${LIBDIR_${ABI}} is unset. Presumably, this is to allow the configure script to set a default libdir automagically. I think 12.3 should be dropped; dolib and einstall should use the logic from 12.5 instead.
(In reply to Mike Gilbert from comment #4) > I think 12.3 should be dropped; dolib and einstall should use the logic from > 12.5 instead. We could do either: - Do this in the next EAPI, i.e. dolib in EAPIs 0 to 8 would use the logic from 12.3, and in EAPI 9 it would follow get_libdir (12.5). In the meantime, the deprecated CONF_LIBDIR variable does no harm. (Also, it is only a default, most of the time LIBDIR_${ABI} will be used.) Or: - Pretend that CONF_LIBDIR never existed, and have dolib* and einstall refer to algorithm 12.5.
Not that Pkgcore uses the following function for dolib* and einstall, which is different from both PMS and Portage: __get_libdir() { local libdir=$1 libdir_var="LIBDIR_${ABI}" [[ -n ${ABI} && -n ${!libdir_var} ]] && libdir=${!libdir_var} echo "${libdir}" }
(In reply to Ulrich Müller from comment #6) > Not that Pkgcore uses the following function for dolib* and einstall, which > is different from both PMS and Portage: Typo, this should read "Note".
(In reply to Mike Gilbert from comment #4) > I think 12.3 should be dropped; dolib and einstall should use the logic from > 12.5 instead. Let's go for this variant. (There was no reply to my query about CONF_LIBDIR on gentoo-dev, from which I conclude that the variable is not used.)
(In reply to Ulrich Müller from comment #8) > (There was no reply to my query about CONF_LIBDIR on gentoo-dev, from which > I conclude that the variable is not used.) gentoo-portage-dev you mean?
(In reply to Sam James from comment #9) > (In reply to Ulrich Müller from comment #8) > > (There was no reply to my query about CONF_LIBDIR on gentoo-dev, from which > > I conclude that the variable is not used.) > > gentoo-portage-dev you mean? No. (Where did I say gentoo-portage-dev?) From: Ulrich Mueller <ulm@gentoo.org> To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Does anyone still rely on the CONF_LIBDIR variable? Date: Wed, 03 May 2023 21:26:37 +0200 Message-ID: <u5y991aj6@gentoo.org>
(In reply to Ulrich Müller from comment #10) > (In reply to Sam James from comment #9) > > (In reply to Ulrich Müller from comment #8) > > > (There was no reply to my query about CONF_LIBDIR on gentoo-dev, from which > > > I conclude that the variable is not used.) > > > > gentoo-portage-dev you mean? > > No. (Where did I say gentoo-portage-dev?) > > From: Ulrich Mueller <ulm@gentoo.org> > To: gentoo-dev@lists.gentoo.org > Subject: [gentoo-dev] Does anyone still rely on the CONF_LIBDIR variable? > Date: Wed, 03 May 2023 21:26:37 +0200 > Message-ID: <u5y991aj6@gentoo.org> I'd expect such a question to come up on the portage development ML as well, which is why I asked. It's a reasonable place to ask whether people are using portage functionality in addition to gentoo-dev. (You didn't say it which is why I asked if you meant it and it was a typo.)
+if
It's in gentoo-dev because this list has wider coverage than the more specialised gentoo-portage-dev (or gentoo-pms) list. We do have a policy against cross-posting, right?
Just asking because as the main person orchestrating portage development at the moment, I expected it there. If it was a conscious decision, I guess that's fine, although in the past we've had occasionally interesting input on that ML because it's lower traffic. Probably worth revisiting such a rule if we're expecting very few or zero replies in the other place. gentoo-dev cross-posted to gentoo-project is different from gentoo-dev and some tiny ML where we're doing it for visibility.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=e5fd7ef3aca87539acc278f2b724e7e47fc4ce41 commit e5fd7ef3aca87539acc278f2b724e7e47fc4ce41 Author: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org> AuthorDate: 2023-04-30 00:00:00 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-10 01:03:08 +0000 Delete remnants of CONF_LIBDIR Support for CONF_LIBDIR was initially added on 2004-08-16 in: https://gitweb.gentoo.org/archive/proj/portage-cvs.git/commit/?id=ecc2faaa00b1e6250129267ba873bedd2121eac5 Support for LIBDIR_${ABI} was initially added on 2005-02-26 in: https://gitweb.gentoo.org/archive/proj/portage-cvs.git/commit/?id=64779fdecc8e4ec7d2cb9a6fa70066694f78231d Since then, CONF_LIBDIR was not used if ABI and LIBDIR_${ABI} were set. CONF_LIBDIR was set only in 2004.3 profiles: https://gitweb.gentoo.org/archive/repo/gentoo-2.git/commit/?id=1482b856ad2a301c8eb2245a7c7265350af2691d LIBDIR_${ABI} was set in profiles starting with 2005.0 profiles: https://gitweb.gentoo.org/archive/repo/gentoo-2.git/commit/?id=054e484d8717a18622615e019e7cd62495365192 https://gitweb.gentoo.org/archive/repo/gentoo-2.git/commit/?id=a1f9392206c050c2b952c3e1281b731f1c969bc9 Bug: https://bugs.gentoo.org/75420 Bug: https://bugs.gentoo.org/267159 Signed-off-by: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org> Closes: https://github.com/gentoo/portage/pull/1032 Signed-off-by: Sam James <sam@gentoo.org> bin/ebuild-helpers/dolib | 12 +++++------- bin/phase-helpers.sh | 25 ++++++++++++------------- lib/portage/tests/bin/test_filter_bash_env.py | 22 +++++++++------------- 3 files changed, 26 insertions(+), 33 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/pms.git/commit/?id=544d28de1b799ffe839bd6d7b5bc15b4d8e5970d commit 544d28de1b799ffe839bd6d7b5bc15b4d8e5970d Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2023-04-29 14:33:48 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2023-05-04 18:39:57 +0000 pkg-mgr-commands.tex: Drop CONF_LIBDIR* and DEFAULT_ABI The CONF_LIBDIR variable was used exclusively in the 2004.3 profile (i.e. it was no longer defined in 2005.0). Portage support for CONF_LIBDIR was added by this commit: https://gitweb.gentoo.org/archive/proj/portage-cvs.git/commit/?id=ecc2faaa00b1e6250129267ba873bedd2121eac5 Note that neither the ABI nor the LIBDIR_${ABI} variable existed at the time. The CONF_LIBDIR_OVERRIDE and DEFAULT_ABI variables were never implemented in the dolib* and einstall commands in Portage. With the three variables dropped, the algorithm is identical to the logic used for get_libdir(). Therefore drop alg:ebuild-libdir and refer to alg:get-libdir instead. Bug: https://bugs.gentoo.org/267159 Signed-off-by: Ulrich Müller <ulm@gentoo.org> pkg-mgr-commands.tex | 30 ++++-------------------------- 1 file changed, 4 insertions(+), 26 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e5edcfd797cfd2f0d3878b8ad6033b2160df83d9 commit e5edcfd797cfd2f0d3878b8ad6033b2160df83d9 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2023-05-06 08:46:30 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2023-05-10 17:57:18 +0000 multilib.eclass: Drop CONF_LIBDIR 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(-)
