Created attachment 295317 [details, diff] fix package-manager.bash to use EROOT instead of ROOT for portageq calls This fixes `eselect news` for compatibility with >=sys-apps/portage-2.2.01.19833 (prefix branch), as well as mainline portage when installed in a prefix, as discussed here: http://archives.gentoo.org/gentoo-alt/msg_4097bbff93bb737f2976d60facb67dc9.xml
Shouldn't it be "${EROOT:-/}" instead of "${EROOT}" everywhere? AFAICS, portageq (from stable Portage) doesn't like an empty second argument.
I think the follwing lines from bin/eselect.in guarantee that EROOT is set: # Support variables for Gentoo Prefix EPREFIX="@EPREFIX@" EROOT="${ROOT}${EPREFIX}"
Yes, it is guaranteed that EROOT is set, but still it may be the empty string.
This should fix it: EROOT=${EROOT%/}/ Like ROOT, it's standard for EROOT to have a trailing slash.
EROOT="${ROOT%/}${EPREFIX%/}/" (although EPREFIX is not supposed to end with a /)
Sorry, but I don't think that anything is broken with the way eselect currently assigns the EROOT variable. EROOT will be identical with ROOT if EPREFIX is empty, and I believe that's how it's supposed to be. (Also I don't know how many of the external eselect modules such a change would break.) It should be fixed in the place where portageq is called in the package-manager module. What's the problem with passing ${EROOT:-/} as argument, which will just avoid the case of an empty string?
Created attachment 295321 [details, diff] fix package-manager.bash to use EROOT instead of ROOT for portageq calls (In reply to comment #6) > It should be fixed in the place where portageq is called in the package-manager > module. What's the problem with passing ${EROOT:-/} as argument, which will > just avoid the case of an empty string? That will work fine. Here's an updated patch.
Revision 856 in trunk.
Fixed in eselect-1.3.
