i'm not sure if this has been filed before and genone couldnt recall anything at the time sooooooooooooooo here it is: if you download a binary package and try to emerge it without doing a whole lot of annoying footwork related to $PKGDIR, it'll fail case in point: wget ftp://blah/sandboxshell-0.1-r1.tbz2 emerge sandboxshell-0.1-r1.tbz2 Calculating dependencies ...done! >>> emerge (1 of 1) app-shells/sandboxshell-0.1-r1 to / !!! CATEGORY info missing from info chunk, aborting... however, if i do this, it'll 'work': mkdir All mv sandboxshell-0.1-r1.tbz2 PKGDIR=`pwd` emerge -K sandboxshell imo, that's just a huge PITA ... the tbz2 file contains all the information it needs in order to determine category and all that hokey, so why aint it working :) test this with Portage 2.0.50-r8 and Portage 2.0.51_pre13 ; both yield same crappy result :x
Ran fixpackages lately?
i highly doubt that's the issue this will happen if your PKGDIR is completely empty and if you generate a tbz2 pkg right then and there
Emerge by path is broken, do the binpkging properly.
then fix the emerge by path :P it's not like you need any information from the path to the tbz2 ... all the CATEGORY, PN, PV, etc... information is stored inside of the tarball
The hilarious part is this is also triggered if you delete PKGDIR in the middle of a long sequence of merging. I was upgrading my Ultra 2 and I had previously removed my 36 gig /home drive, so I have no space for binpkgs and forgot to remove the FEATURE. So I rm -rf'd /home/packages to make sure / didn't fill up. Sure enough the next package died horribly with the same error.
In order to support this a virtual repository could be generated to contain binary packages that are given on the command line. This approach would allow the resolver to view the package as coming from a repo so that it doesn't have to treat it as a special case.
