As a result of bug 773469 (which I filed), passing --binpkg-respect-use=y forces --autounmask-use=n. After trying this for a while, I think this change was too aggressive. In particular, it disables autounmask even when none of the packages that need use changes have binpackages available and produces slot conflicts instead. Additionally, with FEATURES=binpkg-multi-instance it is pretty reasonable to want to build a second binpkg with different use flags, particularly with repositories shared across multiple machines. (It also takes effect with --usepkg=n, but that would presumably be easy to fix.) I think in this case the cure has been worse than the disease, and I suggest reverting it.
(In reply to William Throwe from comment #0) > As a result of bug 773469 (which I filed), passing --binpkg-respect-use=y > forces --autounmask-use=n. After trying this for a while, I think this > change was too aggressive. In particular, it disables autounmask even when > none of the packages that need use changes have binpackages available and > produces slot conflicts instead. Additionally, with > FEATURES=binpkg-multi-instance it is pretty reasonable to want to build a > second binpkg with different use flags, particularly with repositories > shared across multiple machines. (It also takes effect with --usepkg=n, but > that would presumably be easy to fix.) The thing is, they are expected to interfere with each other as described in bug 773469 comment 0, so we would have to come up with some kind of mechanism to prevent this interference. > I think in this case the cure has been worse than the disease, and I suggest > reverting it. Hmm, well I'll have to take some time to consider whether that's viable given the way(s) that they would interfere.
For optimal --binpkg-respect-use like behavior with multiple use combinations available and there is no exact match, you really need a scoring system as discussed in bug 777111.
