Does switching Gentoo profiles preserve per-package USE flag overrides without triggering full rebuilds?

Short answer

Yes, in most cases. A per-package -flag entry in /etc/portage/package.use is preserved across a profile switch and is evaluated after the profile's defaults, so it cancels a profile-added +flag. When the net effective USE set for a package is unchanged, emerge --changed-use @world does not select that package for rebuild. The rebuild candidates you see in the pretend output are the packages whose effective flags actually changed — not every package the new profile touches.

How the resolution works

Portage merges USE flags in a defined order: profile make.defaults first, then make.conf globals, then package.use per-package entries (with use.force/use.mask able to override everything). Switching from default/linux/amd64/17.1 to the desktop/gnome sub-profile adds flags like systemd and pulseaudio at the profile layer only. An existing package.use line such as media-sound/foo -pulseaudio still wins for that package, so its effective set is identical before and after the switch, and --changed-use — which compares the symmetric difference of effective sets — skips it.

One caveat: this describes long-standing, well-established Portage behavior, but exact --changed-use edge cases have varied across Portage releases. Treat the pretend output, not assumptions, as authoritative for your installed version.

Verifying per package

The definitive query is the pretend merge itself, plus a direct flag dump:

emerge --pretend --verbose --changed-use @world
emerge --info | less            # global effective USE
portageq envvar USE             # resolved global set

For a single package, emerge -pv category/package shows the resolved per-package flags with their origin (flags from package.use are shown distinctly from profile defaults). If a package you expected to be protected by a negation still appears as a rebuild candidate, check for use.force in the new profile — a forced flag cannot be negated by package.use, and GNOME profiles force some flags.

Binary packages

emerge --usepkgonly can reuse a cached binary only when the binary's recorded USE (and USE_EXPAND values like USE= groups for ABI_X86, PYTHON_TARGETS, etc.) exactly matches the current effective configuration. Matching the visible USE string is not sufficient — binaries built under the old profile may differ in USE_EXPAND settings resolved at build time, in which case Portage correctly falls back to a source build. Inspect a binary's metadata with qxpak or emerge --pretend --usepkgonly --verbose to see why a cached package was rejected.

Recommended sequence

1. Run emerge -pv --changed-use @world immediately after eselect profile set and save the list.
2. Add any missing per-package negations to package.use, then re-run the pretend merge; packages whose effective set is now unchanged should drop off the list.
3. Only then run the real merge, adding --usepkg if you want binaries considered, and expect source rebuilds where USE_EXPAND or forced flags genuinely changed.

If a package still rebuilds despite a matching negation, the missing diagnostic is whether the flag is use.forced in the new profile — check portageq get_repo_path / gentoo and inspect the profile's use.force files before assuming a Portage bug.