Bug 556592 – sys-apps/portage: autounmask should (add an option to) prefer unmasking lowest, rather than highest, version satisfying dependencies

• Product: Portage Development
• Status: RESOLVED WONTFIX

[Description Jonathan Lovelace 2015-08-03 18:35:05 UTC]

I run a mostly-stable system, but use a few ~arch-only packages and frequently add versions to package.accept_keywords because they fix tests or include a bug fix I need. When I try to install an ~arch package for the first time, or the version I had installed is removed in favor of a newer version, it frequently requires adding additional deps to package.accept_keywords. However, when only one of the unstable versions of a package can satisfy a dep, the autounmask algorithm always proposes the highest version, even if a lower version would require adding many fewer of its deps to package.accept_keywords. I have to look through the ebuilds by hand to see which of the versions that autounmask proposes to accept are actually necessary, and which of the deps could be satisfied by a lower version. I would prefer if Portage could be made to try autounmasking lower-version packages before higher-version ones.

Reproducible: Always

[Comment 1 Brian Dolbec (RETIRED) 2015-08-03 19:29:35 UTC]

Short answer, no.

Longer answer, Portage is already getting too many cli options.  Also portage has always choosen the highest available version number. 
Adding in even more logic to an already overloaded and slow dependency resolver is not going to happen.  There is too much AI (artificial intelegence) needed to figure out if it should be the lowest masked or highest... depends on the problem and which it was fixed in, which of the ~arch keyworded pkgs are going to be stabilized by the maintainer next,... 

That is what the system maintainer is to decide.  Mask or unmask the pkg-version desired if you don't like the choice made by autounmask.  That's why it give you the choice to accept it of reject it's choice.