AllenJB <gentoo-li...@allenjb.me.uk> writes: > First of all, a tip: If a portage upgrade is available, do "emerge > portage" first. New versions of portage often have new or improved > features - in this case portage 2.1.6 includes, among other things, > the ability to automatically handle most blockers.
Though even the portage2.2 pre-releases do not handle all the cases that should be able to be handled automatically. An example is one which encountered yesterday - foo-x-y-z was already installed and foo-x-y+1-0 was available for update. There are already installed packages which have (R)DEPEND="=foo-x.y*" and others with (R)DEPEND=">=foo-x.0.0". So the already installed foo-x.y.z satisfies all the depends, but the new foo-x.y+1.0 does not. Yet 'emerge -auDv world' flagged a conflict of trying to install two versions of an unslotted package - when the 'obvious' resolution would be keep the already installed version and not upgrade rather than requiring the user to manually mask the new version. Not only is this less work for the user, but it would also allow the automatic upgrade if and when the packages with the specific dependency on the lower version were changed to allow the newer one without the user having to track the blocking ebuilds to see when the (R)DEPENDs change and then manually remove the mask.
