| Summary: | sys-apps/portage and app-portage/gentoolkit don't appear to support multilib-style LIBDIR settings | ||
|---|---|---|---|
| Product: | Gentoo/Alt | Reporter: | Stuart Shelton <srcshelton> |
| Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | IRIX | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
well, not really, as the consensus is that portage installs word-size agnostic code, python files ... In reply to comment #0) > IRIX has always stored legacy/old 32bit libraries in /lib, modern n32 32bit > libraries in /lib32, and 64bit libraries in /lib64. > > I decided to try to implement this schema under Prefix Portage by adding the > following to my make.conf: We killed off multilib support in Gentoo Prefix close to a year ago now. (iirc). The reason is simple: a) multilib is annoying. b) the user has the choice to install 32bit, 64bit, or both prefix's if they want to without any harm. I wonder if $(get_libdir) is actually the right thing to do in the portage ebuild hmmm, Jeremy actually has a point, we (prefer to) only do a single target in Prefix Changes to gentoolkit-0.2.4.4.ebuild:
--- gentoolkit-0.2.4.4.ebuild
+++ gentoolkit-0.2.4.4.ebuild
@@ -31,8 +31,8 @@ src_unpack() {
ebegin "Adjusting to prefix (sloppyly)"
find . -mindepth 2 -type f | grep -v Makefile | xargs sed -i \
- -e
"s|/usr/lib/gentoolkit/pym|${EPREFIX}/usr/lib/gentoolkit/pym|g" \
- -e "s|/usr/lib/portage/pym|${EPREFIX}/usr/lib/portage/pym|g" \
+ -e
"s|/usr/lib/gentoolkit/pym|${EPREFIX}/usr/$(get_libdir)/gentoolkit/pym|g" \
+ -e
"s|/usr/lib/portage/pym|${EPREFIX}/usr/$(get_libdir)/portage/pym|g" \
-e "s|/usr/share/|${EPREFIX}/usr/share/|g" \
-e "s|^#!/usr/bin/python|#!${EPREFIX}/usr/bin/python|g" \
-e "s|^#!/bin/bash|#!${EPREFIX}/bin/bash|g" \
@@ -59,7 +59,7 @@ pkg_postinst() {
use prefix || chown root:root "${EROOT}/var/cache/revdep-rebuild"
chmod 0700 "${EROOT}/var/cache/revdep-rebuild"
- python_mod_optimize /usr/lib/gentoolkit
+ python_mod_optimize /usr/$(get_libdir)/gentoolkit
einfo
elog "The default location for revdep-rebuild files has been moved"
@@ -73,5 +73,5 @@ pkg_postinst() {
}
pkg_postrm() {
- python_mod_cleanup /usr/lib/gentoolkit
+ python_mod_cleanup /usr/$(get_libdir)/gentoolkit
}
Note that gentoolkit's test-suite fails with:
>>> Test phase [test]: app-portage/gentoolkit-0.2.4.4
make -j1 test
make -C src/echangelog test
make: *** src/echangelog: No such file or directory. Stop.
make: *** [test] Error 2
* ERROR: app-portage/gentoolkit-0.2.4.4 failed:
* Make test failed. See above for details.
*
* Call stack:
* ebuild.sh: 42: <call src_test>
* environment:2503: <call _eapi0_src_test>
* ebuild.sh: 612: hasq test $FEATURES &&
die "Make test failed. See above for details."
... seemingly because echangelog doesn't exist within the src directory.
I must admit that I moved my main box over to using lib32 out of a (quite possibly misplaced ;) sense of correctness. Having said this, with things such as nss looking as if they're only ever going to build in (o)32 mode (e.g. lib) and some other ebuild which I don't recall the name of right now only having support for 64bit MIPS code (lib64) is does seem to be a useful thing to have... for IRIX at least. In any case, I'm not suggesting that all of prefix should be forced back to a multilib approach - just that it would be handy for those who want/need it if portage (of all things!) does the right thing... This change to the portage ebuild allows multilib builds to succeed - but it is definitely a hack... --- portage-2.2.00.13797.ebuild +++ portage-2.2.00.13797.ebuild @@ -9,7 +9,7 @@ inherit eutils multilib python DESCRIPTION="Prefix branch of the Portage Package Manager, used in Gentoo Prefix" HOMEPAGE="http://www.gentoo.org/proj/en/gentoo-alt/prefix/" LICENSE="GPL-2" -KEYWORDS="~ppc-aix ~x64-freebsd ~x86-freebsd ~ia64-hpux ~x86-interix ~amd64-linux ~ia64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris" +KEYWORDS="~mips-irix ~ppc-aix ~x64-freebsd ~x86-freebsd ~ia64-hpux ~x86-interix ~amd64-linux ~ia64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris" PROVIDE="virtual/portage" SLOT="0" IUSE="build doc epydoc selinux linguas_pl prefix-chaining" @@ -137,7 +137,21 @@ src_install() { local portage_base="/usr/${libdir}/portage" emake DESTDIR="${D}" install || die "make install failed." - dodir /usr/lib/portage/bin + + if [[ "$libdir" != "lib" ]]; then + if [[ -d "${ED}/usr/lib/portage" ]]; then + ewarn "Moving portage installation into ${libdir} ..." + mv "${ED}"/usr/lib "${ED}/usr/${libdir}" + fi + + for x in "${ED}"/usr/*bin/* ; do + [ ! -L "${x}" ] && continue + ewarn "Adjusting ${x} ..." + ln -sf "../${libdir}/portage/bin/$( basename "${x}" )" "${x}" + done + fi + + dodir /usr/${libdir}/portage/bin if use userland_GNU; then rm "${ED}"${portage_base}/bin/ebuild-helpers/sed || die "Failed to remove sed wrapper" The problem here actually is that "the right thing" in (Gentoo) Linux terminology is that /lib is a symlink to the native word-size libdir. That symlink is created by baselayout, and hence portage installing into /lib ends up fine... Hmm - I guess we have two fundamentally different concepts of what "lib" should be here... (Oh, and the ebuild from that last comment does break things - please ignore it!) can an application using the new format (lib32) link against a lib from the old format (lib)? I think 64-bits/32-bits is out of the question here, but it may make sense if you have two 32-bits formats that can both be used, and for some reason both in use as certain applications only generate the old format or something. Ideally it's just forcing/fixing everything to produce new-style (lib32) objects and put them -- Prefix-style -- in lib. See how we did the 64-bits Solaris targets, they are just a full new Prefix with another location but exactly the same layout, using "lib". Unfortunately, no - o32 and n32 code are completely different binary formats, and so cannot interoperate. All I can do is re-iterate my suggestion that since portage is the only package which doesn't install into lib32 when $(get_libdir) returns 'lib32', it seems that it would be more elegant if portage also behaved in this manner - so long as nothing else is broken in the process. (Since other platforms have lib symlinked to $(get_libdir), this would presumably have no impact from their point of view. The portage ebuild does appear to install one binary as 'usr/lib/portage/bin/chpathtool', possibly justifying the change?) this just isn't likely to happen, as the design of Gentoo is different |
IRIX has always stored legacy/old 32bit libraries in /lib, modern n32 32bit libraries in /lib32, and 64bit libraries in /lib64. I decided to try to implement this schema under Prefix Portage by adding the following to my make.conf: ABI="mips32" DEFAULT_ABI="mips32" LIBDIR_mipso32="lib" LIBDIR_mips32="lib32" LIBDIR_mips64="lib64" With this in place and the entire installed system re-installed, only two packages (out of 249) have files remaining in "${EPREFIX}/usr/lib" (with "${EPREFIX}/lib" being empty). These two remaining packages are portage itself, and gentoolkit. In this configuration, portage (as of sys-apps/portage-2.2.00.13797) actually fails to build with the following error: ( cd /usr/opt/gentoo/var/tmp/portage/sys-apps/portage-2.2.00.13797/image//opt/gentoo/etc && ln -s /usr/opt/gentoo/var/tmp/portage/sys-apps/portage-2.2.00.13797/image//opt/gentoo/usr/share/portage/config/make.globals ) make[1]: Leaving directory `/usr/opt/gentoo/var/tmp/portage/sys-apps/portage-2.2.00.13797/work/prefix-portage-2.2.00.13797/cnf' make[1]: Entering directory `/usr/opt/gentoo/var/tmp/portage/sys-apps/portage-2.2.00.13797/work/prefix-portage-2.2.00.13797' make[2]: Entering directory `/usr/opt/gentoo/var/tmp/portage/sys-apps/portage-2.2.00.13797/work/prefix-portage-2.2.00.13797' make[2]: Nothing to be done for `install-exec-am'. make[2]: Nothing to be done for `install-data-am'. make[2]: Leaving directory `/usr/opt/gentoo/var/tmp/portage/sys-apps/portage-2.2.00.13797/work/prefix-portage-2.2.00.13797' make[1]: Leaving directory `/usr/opt/gentoo/var/tmp/portage/sys-apps/portage-2.2.00.13797/work/prefix-portage-2.2.00.13797' rm: cannot remove `/usr/opt/gentoo/var/tmp/portage/sys-apps/portage-2.2.00.13797/image/opt/gentoo//usr/lib32/portage/bin/ebuild-helpers/sed': No such file or directory * ERROR: sys-apps/portage-2.2.00.13797 failed: * Failed to remove sed wrapper * * Call stack: * ebuild.sh: 42: <call src_install> * environment:2592: rm "${ED}"${portage_base}/bin/ebuild-helpers/sed || die "Failed to remove sed wrapper"; ... the actual problem is deeper, however, as the "image" directory contains "opt/gentoo/usr/lib" rather than "opt/gentoo/usr/lib32" - so the attempt to remove the sed wrapper is being made from the correct location, but the actual install location is incorrect (as regards the result of "$(get_libdir)", which every other package adheres to). The app-portage/gentoolkit-0.2.4.4 ebuild, however, simply hard-codes "/lib/" - this should be replaced with "$(get_libdir)".