I saw today emerge autounmask behavior with USE changes: # USE="doc" emerge -1av --digest gtkmm:2.4 * * The --digest option can prevent corruption from being noticed. The * `repoman manifest` command is the preferred way to generate manifests * and it is capable of doing an entire repository or category at once. * These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-libs/gd-2.0.35-r1 USE="fontconfig* jpeg png truetype xpm" 0 kB [ebuild N ] media-gfx/graphviz-2.26.3-r2 USE="cairo doc gtk java nls perl python -examples -lasi -ruby -static-libs -tcl" 0 kB [ebuild N ] app-doc/doxygen-1.7.3 USE="doc latex qt4 -debug -nodot -tcl" 0 kB [ebuild U ] dev-cpp/gtkmm-2.24.1 [2.24.0] USE="doc* test -examples" 0 kB Total: 4 packages (1 upgrade, 2 new, 1 reinstall), Size of downloads: 0 kB The following USE changes are necessary to proceed: #required by media-gfx/graphviz-2.26.3-r2, required by app-doc/doxygen-1.7.3[-nodot], required by dev-cpp/gtkmm-2.24.1[doc], required by gtkmm:2.4 (argument) =media-libs/gd-2.0.35-r1 fontconfig NOTE: This --autounmask behavior can be disabled by setting EMERGE_DEFAULT_OPTS="--autounmask=n" in make.conf. Use --autounmask-write to write changes to config files (honoring CONFIG_PROTECT). From my point of view, USE changes are usually needed for newer versions (at least with the same SLOT) and, then, there is no much sense on adding: =media-libs/gd-2.0.35-r1 fontconfig I would simply add "media-libs/gd fontconfig" to prevent to have to add a ton of lines to package.use with any new "gd" version. Thanks a lot Reproducible: Always
When choosing these atoms, it's not necessarily safe to use really broad atoms. For this particular case it seems like we can optimize it more though. The '=' operator might be appropriate if we were making a package.unmask change, but it's too specific for a package.use change. One problem with the current code is that it uses '=' if the selected package is not the latest version available in its slot, and this is almost never true for stable packages.
*** This bug has been marked as a duplicate of bug 379333 ***
