Two examples of the use of the Python "abspath" function in the "emerge" program are line 290: if (x[-7:] == ".ebuild" or x[-5:] == ".tbz2") and os.path.exists(os.path.abspath(x)) and line 1025 (note that line 1024 is elif x[-7:]==".ebuild") : mykey=os.path.basename(os.path.abspath(x+"/../.."))+"/"+os.path.basename(x)[:-7] Both examples seem to indicate a misunderstanding about how the abspath function works. If the full path of my current working directory (i.e., the one that I use to start the program that contains the abspath functions) is /a/b/c/d and the value of x is /X/Y/Z, then os.path.abspath(x) generates "/X/Y/Z." However, if x is X/Y/Z -- note the missing first "/" -- then os.path.abspath(x) generates "a/b/c/d/X/Y/Z." In other words, if the variable of abspath is a full path name starting with "/," then abspath responds with that full path name. If it isn't, then the output of abspath reflects the path of the working directory that was used to start the Python program. (See, e.g., http://docs.python.org/lib/module-os.path.html.) Hence, if I execute "emerge cubetest-0.9.0.ebuild" while in the "/usr/portage/games-kids/cubetest directory," then line 290 above is True and the output "mykey" of line 1025 is "games-kids/cubetest-0.9.0." Both results are the expected results. Line 290 results in a warning message about "emerging from path." The warning message goes on to say that "oneshot" will be added to options, but, in fact, it is not. However, if I execute "emerge cubetest-0.9.0.ebuild" from my home directory ("/home/ivar") -- and I know of no good reason not to do this -- then "os.path.abspath(x)" generates "/home/ivar/cubetest-0.9.0.ebuild," which is garbage. Line 290 is then False, which means the warning message about "emerging from path" is skipped, and "mykey" from line 1025 becomes "home/cubetest-0.9.0," which results in a misleading error message about a need to adjust PORTDIR or PORTDIR_OVERLAY. The error is in the use of the abspath function, not in these parameters. The abspath function appears a few other times in portage software. I haven't checked whether similar errors can occur in these cases. I have not suggested some alternative code for these examples because I am dubious that lines 289 through 294 and lines 2024 through 1037 should be in the "emerge" script at all. I suspect this code was included as a part of some "emerging by path" effort. I am not sure I understand what "emerging by path" is supposed to do. My impression is that "emerging by path" is supposed to allow the emerging of packages from locations outside the normal portage tree but I may be wrong. The current emerge program seems to assume that if the package name entered by the user has an ".ebuild" suffix, then, regardless of the package's location, that package is to be "emerged by path" and, hence, is not to be included in the "world" file. (If the lines are deleted, then other code will have to added to the emerge script, probably including a line stripping ".ebuild" from the package name around line 1039.) Ivar Reproducible: Always Steps to Reproduce: 1. See Details 2. 3. Actual Results: See Details Expected Results: Depends on the purpose of "emerging by path." Portage 2.0.51-r3 (default-linux/x86/2004.0, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.9-gentoo-r4 i686) ================================================================= System uname: 2.6.9-gentoo-r4 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux-headers-2.4.19-r1,sys-kernel/linux-headers-2.4.21-r1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="ftp://gentoo.mirrors.pair.com/ http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aalib alsa apm arts avi berkdb bitmap-fonts cdr crypt cups directfb doc dvd encode esd f77 fam firebird flac foomatic foomaticdb fortran gdbm gif gpm gtk gtk2 imagemagick imlib jpeg kde ldap libg++ libwww mad mikmod mmx motif mozilla mpeg mysql ncurses nlsoggvorbis opengl oss pam pdflib perl png postgres python qt quicktime readline scanner sdl slang spell sse ssl svga tcltk tcpd tiff truetype usb x86 xml xml2 xmms xv zlib"
How you just described the function of the code is its exact intention. About the only extra thing that should be done, at this stage, is to check whether the path given actually exists and error out on that. Any time a package name ends in .ebuild, it must be a path. If it is not a path, it's invalid as a package name or atom anyway. Those warning messages and tests are just explaining what happens when emerging by path. You can remove those lines from your own code if you want, but the behaviour won't change.
