Portage, when building packages with FEATURES=binpkg-multi-instance, saves built packages to a different path name, e.g with build ID in the file name and xpak instead of tbz2 as the extension, compared to when FEATURES=-binpkg-multi-instance is (by default) set, e.g.: -binpkg-multi-instance: $PKGDIR/sys-devel/make-4.1-r1.tbz2 +binpkg-multi-instance: $PKGDIR/sys-devel/bc/bc-1.06.95-r2-1.xpak qmerge computes the path using the category, package name and version only: https://gitweb.gentoo.org/proj/portage-utils.git/tree/qmerge.c?id=40c86daf547ed9f296d292e0ea8a87be741af90e#n1316 Reproducible: Always Steps to Reproduce: on binhost: 1. # rm -fr /usr/portage/packages 2. # FEATURES="binpkg-multi-instance" emerge --buildpkg $aPackage 3. # cd /usr/portage/packages && python -mhttp.server # serve this directory as a binhost on port 8000 on another machine: 1. PORTAGE_BINHOST="http://binhost.machine.ip.address:8000/" qmerge -y $thatSamePackage Actual Results: After downloading and parsing of the Packages file, qmerge attempts to download a tbz2 file from the binhost, receives a 404 not found and exits Expected Results: qmerge downloads and installs binary package(s) from the binhost qmerge could use the PATH: information from the Packages file (or compute it with other pieces of information in the Packages file such as BUILD_ID:). It is also possible to have packages in a mixed configuration, if some packages have been built with FEATURES=-binpkg-multi-instance and (e.g. if later turned on in make.conf) FEATURES=binpkg-multi-instance (i.e. some packages with BUILD_IDs and .xpak format and some in .tbz2)
See also the work in https://github.com/gentoo/portage-utils/pull/16. Not sure if that resolves this or not though (not checked).
