Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 556592 - sys-apps/portage: autounmask should (add an option to) prefer unmasking lowest, rather than highest, version satisfying dependencies
Summary: sys-apps/portage: autounmask should (add an option to) prefer unmasking lowes...
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Portage team
Depends on:
Blocks: autounmask
  Show dependency tree
Reported: 2015-08-03 18:35 UTC by Jonathan Lovelace
Modified: 2015-08-04 19:04 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
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 gentoo-dev 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.