qfile -R behaves confusingly on prefix, as if EPREFIX is included in ROOT. % printenv ROOT % printenv EPREFIX /Users/tetsushi/Gentoo % qfile -qC /Users/tetsushi/Gentoo/usr/share/emacs/site-lisp/wl/wl.elc app-emacs/wanderlust % qfile -qCR /Users/tetsushi/Gentoo/usr/share/emacs/site-lisp/wl/wl.elc % qfile -qCR /Users/tetsushi/Gentoo/Users/tetsushi/Gentoo/usr/share/emacs/site-lisp/wl/wl.elc app-emacs/wanderlust % ls /Users/tetsushi/Gentoo/Users ls: cannot access /Users/tetsushi/Gentoo/Users: No such file or directory As descibed in "Gentoo Prefix Techdocs", ROOT is ROOT and there's another variable EROOT = ${ROOT}${EPREFIX} to include EPREFIX. Then, I think qfile -R should not consider about EPREFIX, but only ROOT. The expected behavior is: % qfile -qCR /Users/tetsushi/Gentoo/usr/share/emacs/site-lisp/wl/wl.elc app-emacs/wanderlust It's same with the result of qfile -qC because I'm not setting ROOT.
I think this title describes the bug better, but it is rather confusing. I guess..try digging around in the portage-utils source and see if there is anything obvious.
Removing portage-utils@g.o from CC per request until this gets resolved and may need to go back to them.
It seems the prefix patch is misusing @GENTOO_PORTAGE_EPREFIX@: char portvdb[] = "var/db/pkg"; char portcachedir[] = "metadata/cache"; -char portroot[_Q_PATH_MAX] = "/"; -char config_protect[_Q_PATH_MAX] = "/etc/"; +char portroot[_Q_PATH_MAX] = "@GENTOO_PORTAGE_EPREFIX@"; +char config_protect[_Q_PATH_MAX] = "@GENTOO_PORTAGE_EPREFIX@/etc/"; should be -char portvdb[] = "var/db/pkg"; +char portvdb[] = "@GENTOO_PORTAGE_EPREFIX@/var/db/pkg"; char portcachedir[] = "metadata/cache"; char portroot[_Q_PATH_MAX] = "/"; -char config_protect[_Q_PATH_MAX] = "/etc/"; +char config_protect[_Q_PATH_MAX] = "@GENTOO_PORTAGE_EPREFIX@/etc/"; Then, qfile works, at least for this case.
fixed, thanks!
