I installed portage onto a non-gentoo linux system. However, emerge will silently fail when attempting to install any package. All other functions of emerge (including emerge sync) worked fine. After much debugging, I was able to determine that the problem was due to ebuild.sh, and it was two-fold. First, I was using bash-2.04 (the one that came in a Redhat RPM), but this version of bash would attempt to execute EXPORT_FUNCTIONS() when ebuild.sh sourced in /var/tmp/portage/<package>/temp/environment - which caused EXPORT_FUNCTIONS() to immediately exit the shell (and thus end the ebuild) because ECLASS was unset. The reason why all ebuilds failed silently was because line 16 of ebuild.sh would send all output of the source to /dev/null, giving no chance for errors to be seen (I assume, to prevent showing errors about read-only variables). I fixed this by removing the '&> /dev/null' from line 16, 'source "${T}/environment" &> /dev/null' and then on line 1863, 'set | egrep -v "^SANDBOX_" > "${T}/environment" 2> /dev/null', I modified to a) grep out the read-only variables BASH_VERSIONINFO, EUID, PPID, EUID, and SHELLOPTS, and b) remove all shell function definitions (such as EXPORT_FUNCTIONS). The real fix was to emerge bash - for some reason gentoo's bash is not affected by this. However, portage and emerge should work even on non-gentoo linux distros, so this is clearly a portage bug. I was unable to find this bug elsewhere, despite extensive searching. Reproducible: Always Steps to Reproduce: 1. Install a bash shell from a Redhat 7.1 system. 2. Run 'emerge patch' or emerge some other package. 3. Actual Results: Emerge would check the mdsums and unpack the package but it would finish there. It did not compile, install, or merge. Expected Results: It should have continued to steps compiling, installing, and merging. 'emerge info' I think is not relevant here. However, it is included as an attachment. (This affected portage 2.0.51.19 as well as 2.0.51.22)
Created attachment 61058 [details] emerge info
(In reply to comment #0) > Steps to Reproduce: > 1. Install a bash shell from a Redhat 7.1 system. Huh??? Sorry, only Gentoo bugs go here, ask Red Hat why their bash from an ancient and for ages unsupported distribution does not work with Gentoo portage. > The real fix was to emerge bash - for some reason gentoo's bash is not affected by this. What a surprise... :)
It is a Portage bug. Portage should be able to work with different bash versions and warn if the version of bash is too old. (As a side note, same version of bash (2.04) but from a gentoo ebuild doesn't have this problem, so bash 2.04 is clearly not too "ancient".) Unless of course Portage requires gentoo bash for gentoo-specific patches, but as far as I know this is not the case. (Sorry for pointing out the obvious, but 'emerge bash' won't do the trick on such a system either - that would silently fail before bash could be installed.) This is easy enough to work around - as I explained, one merely needs to edit ebuild.sh to strip the shell functions and read-only variables from the temp environment file. (The code I used didn't work correctly, it sometimes mangled other environment variables. That's the only reason I emerged gentoo's bash.)
Portage explicitly depends on >=bash-2.05a and is not designed to run on RH 7.1. That
Portage explicitly depends on >=bash-2.05a and is not designed to run on RH 7.1. That´s about it.
You're using an unsupported configuration so you're really on your own, but try to have all the dependencies that portage requires (such as >=bash-2.05a) before reopening and/or opening any other bug reports.
