--- net-misc/dhcpcd/dhcpcd-6.0.3.ebuild +++ net-misc/dhcpcd/dhcpcd-6.0.3.ebuild @@ -38,7 +38,7 @@ use elibc_glibc && hooks="${hooks} --with-hook=yp.conf" econf \ --prefix="${EPREFIX}" \ - --libexecdir="${EPREFIX}/lib/dhcpcd" \ + --libexecdir="${EPREFIX}/$(get_libdir)/dhcpcd" \ --dbdir="${EPREFIX}/var/lib/dhcpcd" \ --localstatedir="${EPREFIX}/var" \ ${hooks} Reproducible: Always
libdir is architecture specific, but not libexecdir, so the ebuild is correct as it stands. The only thing dhcpcd installs in libexecdir is scripts.
The bug is about ${EPREFIX}/lib and not ${EPREFIX}/usr/libexec. So I believe the bug is valid
markos ~$ qlist dhcpcd|grep lib /lib/dhcpcd/dhcpcd-run-hooks /lib/dhcpcd/dhcpcd-hooks/01-test /lib/dhcpcd/dhcpcd-hooks/50-ntp.conf /lib/dhcpcd/dhcpcd-hooks/10-mtu /lib/dhcpcd/dhcpcd-hooks/50-yp.conf /lib/dhcpcd/dhcpcd-hooks/02-dump /lib/dhcpcd/dhcpcd-hooks/20-resolv.conf /lib/dhcpcd/dhcpcd-hooks/29-lookup-hostname /lib/dhcpcd/dhcpcd-hooks/30-hostname /usr/lib/systemd/system/dhcpcd.service
First of all, /lib/<package> or /usr/lib/<package> is a valid libexec directory. Then, does it make in any scenario sense to have files from /lib/dhcpcd both 32bit and 64bit? I'd say no, so it's just like udev where it doesn't make sense to have both 32bit and 64bit helpers like `v4l_id` or such. Then there's nothing to do here...