On 2016-12-19 18:58:43 +0000, Joe wrote: > On Mon, 19 Dec 2016 12:38:51 +0100 > Vincent Lefevre <vinc...@vinc17.net> wrote: > > But that's not automatic (aptitude can also do that, and one can > > undo a choice if it yields removals). > > Difficult to see how it could be automated, as sometimes it's a value > judgement as to whether to temporarily sacrifice application x in order > to upgrade y immediately, or whether to wait a while. Occasionally, a > package is removed permanently, and there's no obvious way of > differentiating such a removal from a temporary dependency issue > without resorting to a search engine.
This is not a problem. All what is needed is to have the choice. Typically, I like to do the following: 1. Upgrade all packages that don't need removals. 2. If some upgrade is blocked, inspect manually what will happen (it's easier to do that if one has handled the non-problematic cases first). Manual inspection is needed because the default choice is sometimes wrong (and only the user can know that). Currently, I can't even do (1) in all cases. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
