When I was running 32-bit gentoo, I was able to do a chroot into a copy of my environment and update my system. After updating it, I would make a quickpkg of all installed packages and move them to my mail system so that the update there would take only a matter of hours rather than a couple days. I've now transitioned to 64-bit (amd64) and tried the same method. This time, though, the emerge (specifically the extraction step) would fail because "/usr/lib/<something>: could not create directory. doesn't exist". This also happened for "/lib/<something>". It appeared that when it would extract from the package, usr/lib in the extraction was still a link to usr/lib64. Since it didn't extract usr/lib64, the directory wasn't there. I thought I could fake it out by copying /usr/lib64 to /usr/lib and /lib64 to /lib in the chroot and then make the packages. It made the packages and they installed for the most part, but they broke my system. Upon investigation, something made broke the link from /lib to /lib64 and made a *real* /lib. cp -a of the stuff in that /lib to /lib64 and recreating the link didn't help. It's still broken. I'm now booting from the 2006.0 CD and chrooting into my main environment to rebuild the whole thing from source. Hopefully that will do the trick. I don't have versions of packages on hand, but it's up-to-date as of 12/23/06 with my main keyword being "amd64" (very little experimental stuff, nothing experimental in the system). I'm afraid I don't have an emerge --info because the system is at home rebuilding itself... Sorry.
This absolute is NOT a supported method of transferring your system from x86 to amd64.
What?!? I didn't mean to say this is *how* I was transitioning from x86 to amd64 (I did that months ago with a complete reinstallation of gentoo), I meant: Since I have transitioned, this method of upgrading (which used to work fine in an x86 system) does not work anymore (on an amd64 system) because quickpkg doesn't handle the symlinks in / and /usr (or anywhere else) correctly.
As a test, on a 64-bit system (with /lib -> /lib64 and /usr/lib -> /usr/lib64) use quickpkg to make a package of any ebuid with files in /lib or /usr/lib. Then use that package to do an emerge -vak On my system it would quickly give an error that it could not create /usr/lib/<whatever>.
i dont see the bug here and your test case doesnt make much sense, plus building a binpkg of udev and then extracting works fine for me on amd64 post some real output rather than trying to describe the error
(In reply to comment #0) > When I was running 32-bit gentoo, I was able to do a chroot into a copy of my > environment and update my system. After updating it, I would make a quickpkg > of all installed packages and move them to my mail system so that the update > there would take only a matter of hours rather than a couple days. FEATURE=buildpkg is the preferred way to have binary packages created. quickpkg is really just for convenience. Note that quickpkg does not add directories that are symlinks due to bug #149781.
I didn't realize that quickpkg made binary packages any less reliably than doing them with emerge. That's good to know. That should probably be mentioned in the manual page and maybe in a wiki or something somewhere, indicate where the packages are extracted (maybe it's in the portage temp dir? I can't test until my system is back to running again) so that the necessary links can be put into place should someone run into this problem after using quickpkg to make a "backup" of a package they are tentatively replacing.
