I have had to call `PORTDIR=../../ repoman ...' on several occasions now because, even with an up-to-date overlay (read PORTDIR in a separate repo updated from CVS), repoman will still use cached information in dependency calculation. By "resetting" PORTDIR I can apparently work around this but it's far from ideal.
For instance, I just saw a bunch of: >>> Creating Manifest for /newaches/gentoo/cvs/gentoo-x86/net-libs/libvncserver dependency.bad 18 net-libs/libvncserver/libvncserver-0.9.9-r3.ebuild: DEPEND: amd64(default/linux/amd64/13.0) ['>=dev-libs/libgcrypt-1.5.3:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]', '>=net-libs/gnutls-2.12.23-r6[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]', '>=dev-libs/libgcrypt-1.5.3:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]', '>=dev-libs/openssl-1.0.1h-r2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]', '>=virtual/jpeg-0-r2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]', '>=media-libs/libpng-1.6.10:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]', '>=sys-libs/zlib-1.2.8-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]'] when the entire CVS repo checkout was already up to date. Oddly enough, I could "reset" this by changing PORTDIR on the command line (as explained in comment #0.
Please reproduce the problem using the repoman -vv option, and post the [DEBUG] messages regarding the repo config. Also, do the same with your magic PORTDIR setting, for comparison.
That might take a while.
I'm mostly just interested in the repo info [DEBUG] messages shown just after repoman starts up. You can kill it after it shows those, instead of waiting for it to to run to completion (if that's what will "take a while").
What takes a while is: 1) wait for rsync to update on one system (twice a day) 2) regenerate metadata on another system (after (1)) 3) on that second system, have a discrepancy in keywords between rsync/cvs repos 4) on that second system, happen to do a repoman check in one of the afflicted packages from (3). It happened maybe twice since I upgraded to sys-apps/portage-2.2.14. I could probably recreate the exact situation, but I'd have to work really hard on it.
I just found that emerge is ignoring PORTDIR= on the command line. Could that be the case with repoman too?
(In reply to Jeroen Roovers from comment #6) > I just found that emerge is ignoring PORTDIR= on the command line. Could > that be the case with repoman too? Repoman still supports PORTDIR environment overrride (thanks to the repoman.utilities.FindPortdir function). I've just tested with repoman -vv, and confirmed that the repo info [DEBUG] outputs show it using PORTDIR from the environment.
(In reply to Jeroen Roovers from comment #6) > I just found that emerge is ignoring PORTDIR= on the command line. Could > that be the case with repoman too? Configuration of repositories can be overridden on command line by setting PORTAGE_REPOSITORIES variable (which is documented in documentation of repos.conf in `man portage`).
repoman support has been removed per bug 835013. Please file a new bug (or, I suppose, reopen this one) if you feel this check is still applicable to pkgcheck and doesn't already exist.
