I need sleep, so I'l double check the exact why and wherefore tomorrow - but it looks as if the ':-root' on $PORTAGE_ROOT_USER in the latest portage ebuild is breaking prefix installs where all files are owned by (for example) portage:portage and the superuser account is never used. If this latest portage release is installed, then any further attempts to perform a (non-pretend) install with fail with "emerge: superuser access is required", breaking the system. I guess that PORTAGE_ROOT_USER could (should?) be set in make.conf - but this hasn't been needed previously (AFAIK), so this does seem to be a major change. (Also, does an installed portage instance check PORTAGE_ROOT_USER, or is this value used to build portage and then hard-coded?)
masked: http://thread.gmane.org/gmane.linux.gentoo.alt/5083/focus=5089
hm... i nearly has a heartattack when i saw that bug - i yesterday upgraded and released a DVD with snapshots for all interix versions - of course including this portage. however doing --sync && -avuD system world was not a problem with those prefixes, even though 14160 was installed (?!). PORTAGE_ROOT_USER is set in /opt/gentoo/usr/share/portage/config/make.globals here. /opt/gentoo/etc/make.globals is a link there. i think with very much older versions of portage, the /etc/make.globals was the real file, and changed to a link sometimes. maybe you still have a real file, whic some values missing/wrong, since the file is stone old?
$EPREFIX/usr/share/portage/config/make.globals also contains PORTAGE_ROOT_USER=root, and $EPREFIX/etc/make.globals is correctly a symlink. Having looked this morning, it still seems to be that in the ebuild PORTAGE_ROOT_USER wasn't previously assigned a value if blank, and there was a discovery mechanism. In the latest ebuild, the value is defaulted to 'root'.
this may be related to not having a recent enough portage when upgrading, I can fix that to try harder to get the right value.
to recover from this, simply do this: - edit $EPREFIX/etc/make.globals ensure PORTAGE_ROOT_USER is set to the correct value - edit $EPREFIX/usr/lib/portage/pym/portage/const_autotool.py check and fix the values of portagegroup, portageuser, rootuser, rootuid and rootgid after that your portage should be willing to operate again
'fraid not - all my affected systems were on at least 2.2.00.13838...
> 'fraid not - all my affected systems were on at least 2.2.00.13838... (Sorry, should have hit "reply" - this was in response to Comment #4)
this should be fixed in the ebuild now, it only happens when you upgrade from a slightly older portage
