The subject ebuild gives during the install phase: make[1]: Leaving directory '/storage/strogdon/gentoo-redlizard/var/tmp/portage/sys-apps/net-tools-1.60_p20151124144947/work/net-tools-1.60_p20151124144947/po' rm: cannot remove ‘/storage/strogdon/gentoo-redlizard/var/tmp/portage/sys-apps/net-tools-1.60_p20151124144947/image/storage/strogdon/gentoo-redlizard//bin/domainname’: No such file or directory rm: cannot remove ‘/storage/strogdon/gentoo-redlizard/var/tmp/portage/sys-apps/net-tools-1.60_p20151124144947/image/storage/strogdon/gentoo-redlizard//bin/nisdomainname’: No such file or directory rm: cannot remove ‘/storage/strogdon/gentoo-redlizard/var/tmp/portage/sys-apps/net-tools-1.60_p20151124144947/image/storage/strogdon/gentoo-redlizard//bin/ypdomainname’: No such file or directory rm: cannot remove ‘/storage/strogdon/gentoo-redlizard/var/tmp/portage/sys-apps/net-tools-1.60_p20151124144947/image/storage/strogdon/gentoo-redlizard//usr/share/man/man1/domainname.1*’: No such file or directory rm: cannot remove ‘/storage/strogdon/gentoo-redlizard/var/tmp/portage/sys-apps/net-tools-1.60_p20151124144947/image/storage/strogdon/gentoo-redlizard//usr/share/man/man1/nisdomainname.1*’: No such file or directory rm: cannot remove ‘/storage/strogdon/gentoo-redlizard/var/tmp/portage/sys-apps/net-tools-1.60_p20151124144947/image/storage/strogdon/gentoo-redlizard//usr/share/man/man1/ypdomainname.1*’: No such file or directory * ERROR: sys-apps/net-tools-1.60_p20151124144947::gentoo_prefix failed (install phase): * (no error message) * * Call stack: * ebuild.sh, line 93: Called __call-ebuildshell 'src_install' * environment, line 184: Called src_install * environment, line 2396: Called die * The specific snippet of code: * rm "${ED}"/bin/{,nis,yp}domainname "${ED}"/usr/share/man/man1/{,nis,yp}domainname.1* || die; The problem in the ebuild seems to be with: src_install() { default Apparently, 'default' causes the install with DESTDIR="${D}" This appears to work: src_install() { # default emake DESTDIR="${ED}" install || die dodoc README TODO
Alternatively, we could preserve any "default" magic by hacking up the makefile like so: src_prepare() { # Upstream's makefile doesn't play nice with prefix ootb sed -e "s|^BASEDIR ?= \\\$(DESTDIR)|BASEDIR ?= \$(DESTDIR)${EPREFIX}|" \ -i Makefile || die default } Then again maybe this cure is worse than the disease. Either way, note that -9999 also needs an equivalent fix.
Created attachment 420892 [details, diff] possibly evil patch to bypass problem. I am getting this too. it appears that the prefix should be applied twice. e.g. the above rm: cannot remove ‘/storage/strogdon/gentoo-redlizard/var/tmp/portage/sys-apps/net-tools-1.60_p20151124144947/image/storage/strogdon/gentoo-redlizard//bin/domainname’ or on my prefix rm: cannot remove ‘/data/gentoo/var/tmp/portage/sys-apps/net-tools-1.60_p20151124144947/image/data/gentoo//bin/domainname’: No such file or directory checking the image directory image/bin/domainname exists but there is no image/data/gentoo/bin/domainname because image/data is not present Now to me it appears that this is the net-tools package being built with DESTDIR=/data/gentoo/var/tmp/portage/sys-apps/net-tools-1.60_p20151124144947/image/ not being built with DESTDIR="${EPREFIX}"/var/tmp/portage/sys-apps/net-tools-1.60_p20151124144947/image/"${EPREFIX}" as I might expect. Unfortunately this is buried down in the emerge plumbing and I think editing ${EPREFIX}/usr/lib/portage/bin/phase-helpers.sh is likely way too big a hammer. but it did allow me to compile and install. I don't know what else it will break though... :( Hum, 12 more packages that would not emerge before have now installed I suppose I could see about changing the src_install() of each of those packages.
(In reply to Steven Trogdon from comment #0) > The subject ebuild gives during the install phase: > > src_install() { > # default > emake DESTDIR="${ED}" install || die > dodoc README TODO Hate to say so since I'm not sure anybody is behind the wheel, but the source of "evil" is technically upstream. They should offer a customizable prefix for installation in addition to respecting DESTDIR like every other upstream does. James, there is no bug in the implementation of default. If you'll allow me a brief moment of pedantry: DESTDIR=${D} signifies, to most Makefiles (including this one), "please take the absolute file path into which each of the presently installed files is ultimately intended to go, prepend "${D}" to it, and install the file there, instead." "${D}" is typically going to be it's default value of: ${EPREFIX}/var/tmp/portage/${CATEGORY}/${P}/image (*) So, since the Makefile is installing files that will ultimately go into file-paths like: ${EPREFIX}/usr/bin/foo, then this recipe yields an absolute, fully realized (unless it traverses a symlink) destination file-path of: ${EPREFIX}/var/tmp/portage/${CATEGORY}/${P}/image/${EPREFIX}/usr/bin/foo |[--------------------${D}-----------------------]==${ED}==| Which is why emake install DESTDIR=${ED} is "wrong": it "should" create a path like: "${D}${EPREFIX}${EPREFIX}/usr/bin/foo" as a predictable GIGO result of the intended semantics of the variables. Coming back to the circumstance at hand: The problem is upstream, insofar as they do not support a customizable installation prefix, but hard code "/usr" as the only supported prefix (nb: this refers to a different "prefix" than the others; i.e., Gentoo usually puts ${EPREFIX}/usr for this, since autotools programs otherwise tend to default to prefix=/usr/local). Upstream /does/ correctly support ${DESTDIR}, which your patch technically abuses, James, to (hopefully) achieve the desired effect (but: if any files are installed by this package with absolute rpaths in them, they would point to the host instead of the prefix, and hence be dead wrong -- this is why some present or future QA bot may correctly insist that such code is a snake in the grass, and your "possibly evil" comment is pretty apt). footnote: (*) Technically, "${D}" is "${PORTAGE_BUILDDIR}"/image according to the wiki, but that sheds not much light on the situation, since the wiki fails to explain or specify from what constituent parts PORTAGE_BUILDDIR is composed, nor what it signifies :D
If ED in DESTDIR doesn't break anything else (install wise), then it's fine. What we used to do to make it clear we did it on purpose to fix something was use DESTDIR="${D%/}${EPREFIX}/" instead.
net-tools doesn't utilize /usr, so having a var for it doesn't make much sense. it does allow overriding for subpaths in its Makefile already: BINDIR ?= /bin SBINDIR ?= /sbin i think the issue is more that the configure phase doesn't record the path, so while normally you'd install EPREFIX at that time, it's all done dynamically here at install time. i've changed the ebuild back to DESTDIR=$ED: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f0bea75ef9fa1e244c0f1c2a84e85c37a729c51d
