gentoolkit: "equery list -p" fails if /usr/portage is a logical link. Reproducible: Always Steps to Reproduce: 1.mv /usr/portage <separate disk> 2.ln -s <new location> /usr/portage 3.equery list -p <any-package; e.g. "xterm"> Actual Results: The installed package is listed correctly. The following list of non-installed packages is empty, although the .elbuild files are present in /usr/portage/<group>/<package>. Expected Results: Also correctly list the non-installed packages. The equery "list" command calls CmdListPackages(), which in case of ["-p", "--portage-tree"] calls gentoolkit.find_all_packages. /usr/lib/gentoolkit/pym/gentoolkit/helpers.py provides : def find_all_packages(prefilter=None): """ ... """ t = porttree.dbapi.cp_all() t += vartree.dbapi.cp_all() if prefilter: t = filter(prefilter,t) t = unique_array(t) t2 = [] for x in t: t2 += porttree.dbapi.cp_list(x) t2 += vartree.dbapi.cp_list(x) t2 = unique_array(t2) return [Package(x) for x in t2] On first glance, I suspect the evaluation of porttree does not follow symbolic links. IFF that holds true, this might imply other more severe failures, needing to raise the severity level of this bug accordingly. man make.conf: ... PORTDIR = [path] Defaults to /usr/portage. Observing that this is not "/usr/portage/" (note the last slash), I tried setting PORTDIR = "/usr/portage/" , but that did not solve the problem. Setting PORTDIR = "<new-destination>" (without finishing slash) explicitly did. The warning in the corresponding man paragraph about the need to adapt the /etc/make.profile symlink does not require any action as long as the /usr/potage-symLink remains correctly functional. ---------------------------------------------------------------------- # emerge --info Portage 2.1.6.4 (default/linux/amd64/2008.0/desktop, gcc-4.3.2, glibc-2.9_p20081201-r1, 2.6.28-gentoo x86_64) ================================================================= System uname: Linux-2.6.28-gentoo-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_5600+-with-glibc2.2.5 Timestamp of tree: Tue, 06 Jan 2009 10:45:01 +0000 app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7-r1, 2.1.6-r1 dev-lang/python: 2.5.2-r7 dev-util/cmake: 2.6.2 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.4_p6, 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.28-r1 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64-sse3 -O2 -pipe " CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib64/fax /usr/share/config /var/lib/hsqldb /var/spool/fax/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=athlon64-sse3 -O2 -pipe " DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://de-mirror.org/distro/gentoo/" LANG="de_DE.UTF8" LC_ALL="de_DE.UTF8" LDFLAGS="-Wl,-O1" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/Storage-B/Portage_tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage"
* installed packages [I--] [ ] sys-apps/portage-2.1.6.4 (0) [I--] [ ] app-portage/portage-utils-0.1.29 (0) [I--] [ ] app-portage/gentoolkit-0.2.4.2 (0)
That is because /usr/portage is a symbolic link. What is happening is the PORTDIR setting is not matching the actual path to the package so equery thinks it is in an overlay. You can see this by running the command equery list -o -p <package> The fix to the problem is to set PORTDIR in /etc/make.conf to the actual path of ypur portage tree and not to the symbolic link.
Created attachment 177839 [details, diff] portdir_symlink.patch If this patch is saved as /tmp/portdir_symlink.patch, then it can be applied as follows: patch /usr/lib/gentoolkit/pym/gentoolkit/package.py /tmp/portdir_symlink.patch
I didn't really like my working as designed answer since portage itself seems to handle the symlink fine. The attached patch should fix the issue.
Created attachment 177841 [details, diff] fix_portdir_symlink.patch Simpler patch that also works with relative path names in the symlink
(In reply to comment #5) > Simpler patch that also works with relative path names in the symlink Paul, I definitely like this nice clean one! Paints the picture much more consistent to portage's behaviour as well as *NIX in general. Already tested it; can confirm as "WORKSFORME". I think this fix should enter into stable. Thanks a lot! Kind regards Manfred
Released in gentoolkit-0.2.4.3
