If profiles/updates/* for a primary repository defines a pkgmove for e.g. sys-devel/llvm -> llvm-core/llvm, and an overlay named for the sake of example "guru" has packages that depend on llvm, then processing global updates will do a few things: - for all ::gentoo packages called sys-devel/llvm, vdb packages will be moved - for all ::gentoo packages, vdb metadata will be sed'ed to follow the move - for all ::gentoo binpackages, if possible the binpackages will be renamed to follow the move What doesn't happen is: - for all ::guru packages, vdb metadata will be sed'ed to follow the move. Of course, the overlay should follow the pkgmove by having someone commit updates to all ebuilds, and then a world update can fix stuff up by... rebuilding the packages. Consequence: although world updates work, and all the installed system files for affected packages exist ok in the expected manner, it's possible at minimum to --depclean the moved package, as the overlay will not actually depend on it, and then you get ld.so errors when you try to run your installed software. We should probably perform pkgmoves defined in all layout.conf masters for a repository, not just pkgmoves for that specific repository. By defining an overlay with a given masters= you are saying you want to inherit behavior from that other repository and depend on its (possibly renamed) stuff.
