The ebuild fails while applying the patch (see output from the generated file below) because I have a local Perforce installation (and thus have defined P4HOST, P4CLIENT, P4PORT and P4USER environment variables). Unsetting all of these resolves the problem. As a side-note, this workaround also works for the fam-oss ebuild, which also failed in the patch phase (but with a very different error message (files already patched)). james root # less /var/tmp/portage/portmap-5b-r7/temp/portmap_5beta.dif-9278.out ***** portmap_5beta.dif ***** ============================= PATCH COMMAND: patch -p0 < /usr/portage/net-nds/portmap/files/portmap_5beta.dif ============================= Get file from_local.c from Perforce with lock? [y] patching file from_local.c Get file Makefile from Perforce with lock? [y] patching file Makefile patching file pmap_dump.8 patching file pmap_set.8 patching file portmap.8 Get file portmap.c from Perforce with lock? [y] patching file portmap.c ============================= ACTUALLY APPLYING portmap_5beta.dif... ============================= Get file from_local.c from Perforce with lock? [y] sh: line 1: p4: command not found patch: **** Can't get file from_local.c from Perforce
i think this falls into the 'portage should attempt to create a sane environment' category
Portage can't create a sane environment if the user is the one making it insane. Portage shouldn't 2nd-judge the users settings. Fix it in the ebuild or explain to me what exactly portage itself is breaking.
The bug is due to the ebuild applying patches (using the patch command). These patch commands are somehow invalid, as can be seen from the fact that the patch command tries to obtain the file from an alternative source. In this case, from my Perforce repository (but in theory you'd see a similar error for other environment-identifiable SCMs). So, in summary, the bug can either be considered as one for the ebuild (invalid or use or incomplete number of switches when applying patches) or for portage (to avoid strange side-effects when emerging, portage should create a sane environment with only a limited number of known settings from the default env). I prefer the latter solution as it is the most robust and increases the chances of ebuilds working across the board, rather than failing once it encounters a setting the developer did not foresee.
please file a new bug about the exact package that is not using `epatch`
